I had so many problem with this one, I worked on this problem for hours, called QB tech support but no answer, just the regular spin on do this and that until I found this.

 

Current setup:

Server-hosted install:  Windows Server 2012 R2

Share:  \\ServerName\QuickBooks mapped to P:\

Note:  The server had TWO functioning Ethernet adapters (192.168.0.7 & .8 in IPv4 and two other addresses in IPv6 space)

Workstations:  All Windows 7

Observations:

Lots of problems with multi-user.  The server’s DB manager would lose its state management of the company file.  Workstations couldn’t find the server and would attempt to re-config the .ND/.DSN files in place on the server share.  Some users couldn’t connect to server using P: drive–decorated mappings but could with \\ServerName\Quickbooks–related paths.

Observed that if I delete the .ND file then QuickBooks will use IPv6-related addresses for the server and mark this in the new file.  It then would fail connectivity to the server.  I’d call this a bug.

Observed that there appears to be code within QB that sometimes uses NetBIOS-based name resolution and sometimes uses DNS.

Observed that the workstation would get a connection to the server, I’d press F2 and see that it’s finding the server on the first Ethernet adapter.  I’d then switch to single-user mode and now the workstation was attached to the second Ethernet adapter.  This could be causing the QuickBooks DB manager a problem in tracking state.  Each time, it would update the .ND/.DSN files with the newly-found IP address.

Fixes:

  • Created desktop items for all users straight to the QBW company file.  Used double quotes to surround paths (given the space character in “Company Files”).  Used UNC-style paths rather than drive letter–style.
  • Disabled the second Ethernet adapter on the server, reconfigured DNS to only use this one adapter to resolve the server name.
  • Marked both QB-related services on the server to automatically start.
  • Manually edited the .ND and .DSN files with the correct IPv4-based IP address, replacing the IPv6-based address or the one associated with the secondary Ethernet adapter.  Did this for both the “Company Files.ND” & .DSN in the parent folder as well as the company file–named versions in the Company Files folder itself.  Important:  Also, I verified that paths were drive letter–based and LOCAL to the server rather than to the workstations.
  • Rebooted the server.
  • Ran the Quickbooks DB manager again on the server and scanned the folder.
  • Ran QuickBooks from the first workstation as Admin, verifying that the “run in multi-user mode” option is checkmarked from the Open Database button.
  • Pressed F2 to verify that the server’s IP address is 192.168.0.7.

Observation:

If someone gets an H202 error and then begins to “fix” the problem under Quickbooks’ guidance… it will corrupt the .ND/.DSN files with file paths which are workstation-centric rather than server-centric.  This then seems to confuse the QB DB manager which then screws up state management for single- versus multi-user.  One should only run the repair tool from the server so that file paths then are server-centric.

Also, when running the repair tool I was notified on two attempts that the file was hopeless and that I ought to restore from backup.  I chose not to do this and was able to fix it as stated above.  So I could have lost hours’ or days’ worth of work by trusting the repair tool.

Keywords:  H101, H202, single-user, multi-user, server, Enterprise Solutions 2015, unrecoverable error, Company Files.DSN, Company Files.ND, UNC, drive mapping”