Primary Issue: Make sure that your firewall is allowing traffic in and out over the ports you've selected in your listener profile(s). You might have to create application "exceptions" in your firewall for your COREHL7 Listener executables (CoreHL7ListenerConfig.exe, COREHL7ListenerService1.exe and COREHL7ListenerServiceX.exe)

Using Network Shares or Mapped Drives

It is very important to remember that running a profile locally is NOT the same as running a profile in a Windows Service. The most common support contact we have EVER had for our server products is because people misunderstand this issue.

When you run locally the program is executing as YOU (the Windows User) and (unless YOU changed it) the Windows Service is NOT. By default the Windows Service will run as the built-in Windows account LocalSystem.

This means that IF when you created your listener profile(s) you selected a data folder which resides on a network share, mapped drive, or NAS (Network Attached Storage) device, you may have an issue when your CORE HL7 Listener services try to run. This is because when running locally YOU have access to these network resources while the service, running as LocalSystem, likely does NOT.

Luckily, if you encounter this scenario, there are a couple of easy fixes to resolve.

1.Change your listener profile and select a data folder which resides on a local HDD and share that folder on your network so that other applications can access it.

2.If #1 is not an option, you will need to modify your CORE HL7 Service(s) and have them run as a Domain User which DOES have access to the network resource you are trying to use. To this just click on the toolbar to open the MS Windows Services, then RIGHT CLICK on the preferred service and select Properties. In the Service Properties go to the Log On tab and enter the domain user you (or your network admin) have created to run the service(s).

Configure Windows Service Logon

SCENARIO 1: You have your CORE HL7 Listener(s) running as Windows Services. When the server reboots your trading partner(s) cannot connect to your Listener(s) even though the services are running. The problem resolves itself if you restart the Service(s).

SCENARIO 2: You have your CORE HL7 Listener(s) running as Windows Services. Throughout the day your trading partner(s) are able to deliver messages to you but then at some point they cannot connect to your Listener(s) even though the services are running. You can test the connection to your listener using the CORE HL7 Simulator and it works? The problem resolves itself if you restart the Service(s).

What is likely happening: The key to understanding what is happening is this statement from the scenario "The problem resolves itself if you restart the Service(s)". Since everything works if you restart the service(s) we know that there's not some type of fundamental error or firewall issue happening. These issues are almost always related to a VPN being used (and usually one that's hosted on the same computer/server as the CORE HL7 Listener).

First you need to understand what happens when a CORE HL7 Listener starts up. It will bind (listen) on the port number selected for EVERY IP Address on the computer. This means that if your server has 10 NIC cards with 10 different IP addresses and your profile port number is 5000 your listener will be listening on ALL 10 IP addresses for HL7 data on port 5000. Now, IF your server has <x> IP address(es) AND also hosts a VPN (or attaches to a VPN) which then assigns the server another IP address <x+1> what does the CORE HL7 Listener do?? Well, it depends on what comes first. If your CORE Listener starts BEFORE the VPN attachment it will bind to <x> IP address(es). If it starts AFTER the VPN attachment it will bind to <x+1> IP Addresses. The same situation applies to Scenario 2. Everything started up fine and the Listener was listening on all IP Addresses (including the dynamically assigned VPN address) but then, for some reason the VPN goes down, and then comes back up. What happens here can vary depending on the VPN configuration, but it MAY result in the CORE HL7 Listener not receiving traffic on the newly re-connected VPN IP address.

How to Fix: There are a couple of things that you can do that will usually alleviate this problem. We recommend that you implement them all if possible.

1.Change the start mode of your CORE HL7 Listener services from "Automatic" to "Automatic (Delayed Start)". This way if your server is creating (or attaching to) a VPN on boot-up the CORE Listener services will start AFTER this occurs.

2.In your Listener Profile(s) implement an idle restart by checking the Restart Listener if idle for too long box.

3.Be proactive and monitor your VPN and restart your CORE Listener services if there's a disruption in service.

See this discussion about installing and removing the Windows Services.