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.
Never had my hands on Server 2012 so I’m guessing the Base Filter Engine service is something new. In any case, you have my sympathy for what you went through. A couple of years ago I wrote about an apparent bug with the firewall in Server 2008:
Nobody said they’d experienced it as well so maybe I was doing something wrong…
Thank you, This fixed my issue, after 3 days of troubleshooting and trying everything else others suggested.
Thank you, this worked for me as well! Also I had an older version of QuickBooks previously installed and the filters were set to QB 2014 folder instead of 2015…something to watchout for.
This worked for me. After hours of troubleshooting on my own and then 3 hours on the phone with QuickBooks Support. They were not able to solve the issue, they simply said, it appears to be a problem with your Servers Firewall settings.
Thanks. Had the same or similar issue (H202). The only way any workstation could access mult-user was if the server was in multi-user first. Intuit gave up on the problem months ago so we’ve been running it this way. You lose one license doing it this way but it was better than nothing.
I was also using WS2012 Esstentials with QB2016. Turning off and back on the Base Filter and Firewall fixed the glitch immediately. Glad I found your post. Hope Intuit is listening so others don’t have to go through the pain we went through.
I can hardly believe I finally found this solution. Ever since I built a new Windows Server 2012 R2, we have been having this problem. We worked for hours with QB support 3 separate times. After the last time, the QB support guy went out and found this article.
When I tried to restart the Base Filter service, my RDP session was dropped and the server was isolated from the network completely. Fortunately I had configured the Intel AMT feature and was able to come through the VPN and use VNC to see that the system encountered an error trying to restart the firewall service. Once I manually restarted, connectivity was restored and I was finally able to connect on port 8019!
I think that QB support will be aware of this now. The bigger question is: when is Microsoft going to fix it?
Actually, I would think it is more up to Intuit to fix their software. Intuit claims Quickbooks has full compatibility with Windows, Microsoft does not claim compatibility with QuickBooks. What you experienced with your RDP session is normal. This is not a fix to do remotely.
I’m an Engineer with QuickBooks. We are really sorry that you were troubled by this issue. I sincerely thank the author for sharing his fix. I also agree that we should have this fix as part of QuickBooks
I’m also glad you were able to solve this issue by restarting the BFE and the Windows Firewall Service. I have been leading the teams that made critical fixes to the H-Series error.
If anyone can help answer couple of my questions I promise to get this fix into QuickBooks immediately:
1. In the latest version of QuickBooks (2015 and 2016) have you guys tried using “QuickBooks Database Server Manager” to scan your server for these issues. We had added the capability to add the server ports and resolve other such issues as part of this application.
2. Or, Did you also try using the latest version of “QuickBooks File Doctor” to resolve the port issues?
Did someone see these issues even after running these tools. These tools were created to fix the ports, UAC and other such problems with sharing your company file on a network. If someone can confirm that they ran these tools and it still did not solve their problem but explicitly restarting the BFE and the Windows Firewall service resolved this issue, then we will have this as part of our support tools as well.
Please help me in making QuickBooks better. I’m again really thankful to the Author and glad for stumbling upon this article. Based on your valued feedback I will definitely take this up into QuickBooks.
I’m glad to see that Intuit is finally looking at this issue. I recently (last month) did another install of Windows 2012 R2 with QuickBooks 2013 and had the same issue. I have not had an install with QuickBooks 2015 or 2016. When I originally put together this post, I went through all the steps that Intuit support could give me including running the QuickBooks File Doctor several times. Since this last install was my first one since I posted the blog articles, I just went directly to my found solution and it worked again.
I will be sending you an email directly at the above address with more details.
Thanks for reaching out.
First, many thanks for penning this article. We addressed the ports and permissions fix in the 2015 release of QuickBooks. If you happen to install either the 2015 or the 2016 version then you will find a tool called “QuickBooks Database Server Manager” that actually fixes a host of issues related to the firewall, ports, permissions, etc. But for older releases (2014,2013, etc) I have this fix as part of the latest version of “QuickBooks File Doctor” as well, you should be able to download it from our support site. The old version of the File Doctor did not have these changes.
If you notice this issue again could you please try these tools first and if it still doesnt work do the usual, i.e. restarting the BFE and Firewall services could you please let me know. If it is something we missed I will have it in asap.Please feel free to write to me, more than happy to learn from experts like you.
Thank you for your continued patronage.
Doubt anyone will see this, but having the same issue with QB 2017. You would think they would have fixed this. I tried to do the BFE restart, nothing. One reason when people ask which accounting software to use I say stay away from QB. Thanks for the article though 🙂
First off, we apologize the inconvenience caused. We have a known issue with QuickBooks not moving towards using dynamic ports. But we have work-arounds and are more than happy to help resolve this issue for you.
Please message me and I can set-up a session with the engineering team at Intuit and have this issue resolved for you.
Again, we at Intuit value our customers and we would request an opportunity to help you in this regard.
How can I get a hold of you? I would love help with this issue.
For Scott and anyone else that might be interested. I have personally talked to Sudeep about this problem and they are working on it. But with any software that is used by millions of people, it takes time to come up with a solution to a problem that you are sure doesn’t break something else.
Thank you for this. After 5 hours or trying everything else including rebooting my server this fixed my issue. Strange that a reboot didn’t fix it since that would have also restarted the BFE service.
So update on this, came in today and QBDB manager was saying firewall was blocking again. Restarting BFE fixed it again, but for me it appears I’ll have to setup a task to do this daily…. Not sure of something is triggering it or what. Maybe backups?
Also forgot to add that I have Server 2012 R2 Standard, not essentials.
I just had this happen to me today on Windows Server 2012 R2 Essentials server running Quickbooks Enterprise 17. I tried restarting the Base Filtering Engine but as i was doing this remotely i got booted and couldnt get back on. I had to have a user go up to the server room and restart the server. This is quite annoying.
Same here…All was working until the last server update. I also used TS to remote in and try to restart BFE…Also got booted off…I was never able to get the QDB manager to work on Server essentials but was able to access the file and utilize multi user mode from a workstation. QB KB says they don’t support QBpro on Server essentials so what gives? Is it supported or not? Looks like there are some work arounds but still all very frustrating…I moved files to a Win7 PC and got it working again but want it to run from the server again if I can get the BFE sorted.
From the last two postings, I suspect that Microsoft changed something in their last patches. I am not having the same problem on my four sites running Windows 2012 R2 Essentials and various versions of QB Data Manager. The only thing I could suggest is to remove the patches installed in the June update and see if the problem goes away. If it does, you know the problem is a patch situation and you can take it up with Microsoft. If their patches cause problems like these, they typically they will not charge for troubleshooting the problem.
If you are in the US you can try calling Microsoft Professional Support at 800-936-4900. I would say up front that the problem started after installing patches.
Thanks Ted! Based on my experience with MS “tech support” I’ll pass and figure it out on my own. This is why MS is losing server base…anyway, thanks for the reply.
Windows 2012 R2 essentials/QB Enterprise users – after an update from Quickbooks Enterprise 2016 to 2017 – ran into this same Base Filtering Engine Service (BFE) issue. Took hours to identify. I do note the solution is in this article – just just have to know where to look – https://community.intuit.com/articles/1502150-error-h101-h202-h303-or-h505-when-opening-your-company-file
under solution 2, 2nd item verify QuickBooks Services – here is the message in that KB article
For Windows Server 2012 Essentials R2 users
Windows Server 2012 Essentials R2 requires that programs be authenticated every time the system boots up. QuickBooks will not pass this authentication. When using that system as a QuickBooks file server, a few steps need to be taken after every reboot or an H202 error will occur.
So this is an issue after ever reboot and it started for us after updating 2016 to 2017 – until this is resolved it makes for a very messy issue – after every reboot for updates we have to muck with services to get multi-user working – and it does not appear you can just turn off BFE without other security implications.
Of further note – for those considering Windows Server 2016 where users also have QuickBooks server installed – You can’t – because its not supported yet and if this is an example of the kind of issues trying to host the database engine on an updated server. I understand 2018 version will add support but you may have to way for bug fixes to shake out. If they have a certified payroll or other extensions, they recommend waiting at least 6 months to shake out bugs
Sudeep – QB file doctor does not help, and QB Server manager does report an issue with the firewall which QB tech support sometimes thinks is a false positive – its not – its the BFE getting in the way. going thru the steps to stop BFE use the QB manager to scan, then restarting services – that is the only workaround.
I would strongly suggest a fix for 2017 to better support servers (both 2012 R2 Essentials and 2016 Essentials – or heck any 2012 r2 / 2016 servers. I suspect may people do not install the full quickbooks application on the server, just the db hosting component – so the testing should be more limited. It would be helpful to know why the 2017 Quickbooks does not pass the verification and earlier ones did.
We are considering buying QB Premier 2017 3 user and the specs requires a Windows Server 2012 R2. My company has Windows 2012 not the R2 version. Does anyone know whether there will be compatibility issues? I called Intuit, spoke to 3 different agents and got different responses.
Windows Server 2012 R2 is a minor upgrade to Windows Server 2012. So the problems and solutions you see mentioned here should be the same with Windows Server 2012 as you see with Windows Server 2012 R2.
Yes – I would expect the same resolution steps for the issue I think the BFE is there in all editions, even 2008 r2.. the Intuit article however was very specifc (2012 R2 Essentials) which struck me as odd. FYI separate but related Today the most recent security updates on a 2008 R2 server broke a QB 2016 enterprise DB engine – would not start and repair did not work but rolled back the updates and presto working again. Did not attempt to reinstall and have yet to determined which update causes a problem and/or possible workarounds. MS may end up pulling an update – in general there seems to be ongoing issues around windows security and the QB database engine, Your experience could be different – do tell ….
I disabled windows firewall & multi-user mode worked for years. Just went and enabled windows firewall & it is now working…I’m wondering if there was a Windows Update that resolved this issue somewhere along the way.