Featured
Troubleshooting Common Network Related Issues
Reference Number: AA-00318 Views: 23873 Created: 10-22-2012 11:19 am Last Updated: 06-28-2018 02:12 pm 0 Rating/ Voters

Troubleshooting Common Network Related Issues

 

Level: Advanced


If you are running QuicDoc and/or Office Therapy Professional versions on a TCP/IP network, there are many possible reasons that the workstations may be unable to communicate with the database server.

Please note that Docutrac cannot troubleshoot or setup TCP/IP networks; it is the responsibility of the end user (or their company) and/or a 3rd party IT company to setup and configure networks.
The following article assumes the reader has some working knowledge of IP networking and various Windows troubleshooting skills.

This article will provide some troubleshooting for very common networking based issues that will cause communication issues with the software and/or database server. This guide does not cover every possible scenario but will cover the most commonly encountered issues. 

IMPORTANT:

Docutrac is not responsible for loss of data or functionality of your computers and/or network from the use of the troubleshooting in this guide. Should you choose to follow this guide, you do so at your own risk. Docutrac strongly suggests you contact your IT Administrator or a competent computer and networking technician.

First things first!

Restart all affected computers including the server. Restart your network hardware if possible. Simply restarting the machines may fix the issue you are experiencing.

Confirm that the workstation is configured to connect to the correct server name and database. The best way is to check the .ini file which is explained later in this document (Appendix A).

Firewalls

 

Firewalls are the most common cause of failures to connect to the server. To verify whether or not your firewall is blocking communication, temporarily turn it off on all computers experiencing the issue; this is very important on the server. In fact, in most cases, the server firewall is blocking the inbound SQL connection.

On the server, you will need to configure your firewall to allow the SQL Server service executable and the SQL Browser service executable. On a 64 bit Windows machine, these files are located at:

SQL SERVER: "C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe"

SQL BROWSER "C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe"

*Note that MSSQL.1 may be different on your system, depending on how many instances of SQL Server are installed. This may not apply if you are using SQL Server 2008.

** On a 32 bit version of Windows, Program Files (x86) will just be Program Files.

TCP/IP Ports:

SQL Server will communicate on port 1433 by default. SQL Browser will communicate on port 1434.

If you need assistance configuring your firewall settings, please contact your firewall support or contact a computer technician.

Another firewall issue is that the workstations firewall may be blocking QD (QuicDoc.exe) and or OT (OTherapy.exe) from making an outbound connection. It is also possible that a sub-program may be blocked as well, such as QuicDocD.exe or ClaimsManager.exe. Make sure that your firewall is not configured to block these programs.

Advanced Network Troubleshooting

 

Best Practices:

·         It is strongly encouraged to assign your server a Static IP address. Ideally, this IP address will not be within your DHCP address pool. For example, your routers DHCP will assign addresses 192.168.1.100 through 192.168.1.150. Assign a static IP outside of this range, but within your subnet, such as 192.168.1.200 or 192.168.1.10.

·         Do not exclusively use external DNS servers, such as OpenDNS, Google DNS, or any DNS set by your antivirus program (i.e. Comodo). If you must use an external DNS server, it is advised to manually assign your local DNS server (this may be your router or a Windows server machine) as your primary, and the external DNS assigned as your secondary DNS.

·         Use of Wireless networking is strongly discouraged due to reliability and security concerns. If you are experiencing connection dropouts in the software, Docutrac Tech Support may advise you to switch to a wired network. 

There are many common error messages that can occur due to improper network configuration; the most common being “SQL Server does not exist or access denied”. If the firewall has been properly configured and/or is turned off, try these troubleshooting tips in attempt to find the issue. 

Ping the Server from the workstation

Open a command prompt. In Windows XP, go to Start, Run, and type cmd and press enter. In Windows Vista or 7, go to Start, type cmd in the search bar, and when CMD.exe appears under Programs, right click and select Run as Administrator.

Official Microsoft TechNet guide to Ping: http://technet.microsoft.com/en-us/library/bb490968.aspxb 

Ping the server using its hostname (computer name). For example, if your server name is “Server01”, type:

ping Server01 -4

Press enter to execute the command.

*The -4 switch will force ping to use IP version 4. This is not necessary if IP version 6 is not installed.

Using this example, and assuming that Server01 has an IP address of 192.168.1.5, a successful ping would look like:

Pinging Server01 [192.168.1.5] with 32 bytes of data:

Reply from 192.168.1.5: bytes=32 time=5ms TTL=128

<Redundant output omitted.>

Ping statistics for 192.168.1.5:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 0ms, Maximum = 5ms, Average = 1ms

*Note that “time” will vary depending on your network conditions. A good network will have a response time of less than a few milliseconds, with best performance if response time is <1ms (less than). TTL may vary and this is not a cause of concern.

If you are receiving successful responses with some dropped packets in between (“Request timed out”) this may be due to a faulty network connection and you should troubleshoot your network hardware. If using wireless networking, switch to a wired network and see if the behavior persists.

If you pinged the server using its hostname and it resolved to an outside IP address, this indicates a problem with your DNS settings. (In this scenario you may or may not successfully ping). To resolve this, follow the advice on DNS settings as described above in Best Practices. In some scenarios, you may have to bypass DNS and code the hostname and local IP address of the server in your workstations host file (see how in Appendix B). To verify DNS name resolution is a problem, ping the server again but instead use the internal IP address (verify the IP is correct and that there is no IP conflict). If there is a successful response, troubleshoot your DNS.

If you pinged the server and received no responses (“Request timed out”), there are a number of causes to this, but generally points to a problem in your network connection. It may also be due to a firewall blocking incoming pings (turn off firewall and try again). Also try pinging using the IP address instead of hostname and see if there is any difference. Examples of issues that may cause this include but are not limited to:

-          Improper TCP/IP configuration on the machine(s)

-          The server and workstation(s) are on separate networks, or are in separate subnets with improper routing between the two. For example the server is on a 192.168.1.0 network and the workstation is on a 192.168.0.0 network. This can happen if you connect to the wrong wireless network.

-          Improper router setup

-          A fault in the physical layer, I.E.: bad cable/RJ45 connection, bad network card, bad switch/router

Another possibility is that TCP/IP itself is damaged or corrupted. You can reset it by following the instructions on this official Microsoft guide to resetting TCP/IP:

http://support.microsoft.com/kb/299357

Important: Following the Reset TCP/IP guide in the link above will reset all networking configuration and may cause loss of functionality and/or network services. Docutrac recommends that a competent IT technician perform this operation. Should you choose to perform this operation yourself, you do so at your own risk.

If you are still experiencing trouble, there may be a configuration problem with SQL server or the program(s).

 

Appendix A: Using the programs INI file to confirm correct server/database settings

 

QuicDoc stores the connection information in the quicdoc.ini file. Office Therapy stores the connection information in the OT3.ini file. The location of these files varies depending on your operating system and whether or not User Account Control is used. When you have located and opened the ini file, instructions for modifying are on the next page.

Opening the QuicDoc.ini file on a Windows XP machine:

Copy and paste this command in a command prompt window or Run box:

notepad "%allusersprofile%\application data\docutrac\quicdoc std\quicdoc.ini"

Opening the QuicDoc.ini file on a Windows Vista/7 machine WITHOUT User Account Control:

Copy and paste this command in a command prompt window:

notepad "%ProgramData%\DocuTrac\QuicDoc Std\quicdoc.ini"

Opening QuicDoc.ini file in Windows Vista/7 WITH User Account Control:

Copy and paste this command in a command prompt window:

notepad "%LOCALAPPDATA%\Local\VirtualStore\ProgramData\DocuTrac\QuicDoc Std\quicdoc.ini”

Opening OT3.ini file on Windows XP:

Copy and paste this command in a command prompt window or Run box:

notepad "%allusersprofile%\application data\docutrac\office therapy\ot3.ini"

Opening OT3.ini file in Windows Vista/7 WITHOUT User Account Control:

Copy and paste this command in a command prompt window:

notepad "%ProgramData%\DocuTrac\Office Therapy\ot3.ini"

Opening OT3.ini file in Windows Vista/7 WITH User Account Control:

Copy and paste this command in a command prompt window:

notepad "%LOCALAPPDATA%\Local\VirtualStore\ProgramData\DocuTrac\Office Therapy\OT3.ini” 

Checking and modifying QuicDoc.ini

Locate the following section and lines:

[SQLServer]

InitialCatalog=QuicDocStd

DataSource=SERVER\DTISQLSERVER

You may see InitialCatalog2, 3, etc. Ignore these.

The database name is always QuicDocStd. Make sure it is entered as shown in the initialCatalog line above.

The DataSource line is the server name. Check the spelling and/or change the server name as necessary. Enter the server name in all capital letters. In the example above, the server name is SERVER and has a named SQL instance of DTISQLSERVER (this is the default with our program installers, but this can be different if SQL was installed separately).

Save and exit notepad when done.  

Checking and modifying OT3.ini

Locate the following lines:

SQLServer=SERVER\DTISQLSERVER

SQLDBName=XYZ

The SQLServer line is the server name. Check the spelling and/or change the server name as necessary. Enter the server name in all capital letters. In the example above, the server name is SERVER and has a named SQL instance of DTISQLSERVER (this is the default with our program installers, but this can be different if SQL was installed separately).

The SQLDBName line is the database name.

Save and exit notepad when done. 

 

NOTE: It is possible that multiple copies of these ini files exist in systems using User Account Control.  

Appendix B: Configuring Windows hosts file

Universal information about the hosts file: http://en.wikipedia.org/wiki/Hosts_%28file%29

Important:

Improper configuration of your hosts file can cause loss of network connectivity. Docutrac is not responsible for managing your hosts file or any loss of functionality resulting from improper use of the hosts file. Docutrac recommends that a competent IT technician make changes to the host file. Should you choose to modify the hosts file, you do so at your own risk.

 

In Windows, during name resolution, the TCP/IP stack checks the hosts file before checking DNS. Thus, if you are unable to change your DNS settings, you can get around this by configuring the host file.

On all supported versions of Windows, the hosts file is located at %Systemroot%\System32\Drivers\Etc\hosts

The hosts file does not have an extension, and should be opened with Notepad. On Windows XP, open the file whichever method you prefer. In Windows Vista/7 with User Account Control, you will need to open it as an Administrator. The best method to do so, open a command prompt as administrator, and copy & paste the following:

notepad %Systemroot%\System32\Drivers\Etc\hosts

Inside the host file, go to the bottom line and enter the IP address first, press Tab, and then enter the hostname. In the example below, using a server name as SERVER01 with an IP of 192.168.1.5, it would look like:

192.168.1.5         SERVER01

Do not specify a SQL instance. This should only be the server computer’s hostname.

Save and close the file when complete. If you are prompted to save as a new file, you did not open as Administrator, and your changes will be lost.

 

 

Quick Jump Menu