CORE HL7 Postmaster
Created with the CORE HL7 API Libraries for .Net 8
Some of the most common support calls we receive are from customers who have either forgotten, or never knew, some important features (behaviors) of Microsoft Windows Services.
When you run any program in Windows, the CORE HL7 Postmaster, Microsoft Word, Chrome, etc, it is important to remember that the program is running as YOU, IE whatever user ID you used to log into Windows. Windows Services on the other hand are run in a separate memory space, and they are running using a DIFFERENT user ID. The CORE HL7 Postmaster, for instance, when it installs windows services they will, by default, use the built-in LOCAL Microsoft account LocalSystem.
It's also very important to remember that BY DESIGN, these built-in LOCAL accounts (like LocalSystem) DO NOT have access to your Network Resources.
How can this affect me?
In several different ways. If any of your folders, like Central Distribution, or Folder Data Sources, or Folder Destinations, are network shares, or NAS (Network Attached Storage) devices, or mapped drives, YOU might be able to see them when you are Running Locally because it is running as YOU. If you use any of the CORE MS SQL Schema Engine interfaces (like CORE SQL Destinations, CORE SQL Data Sources, or CORE SQL Assemblers) and you have elected to use the Windows Trusted Connection in your CORE MS SQL Database Connector, everything might work swimmingly when you Run Locally. This is because YOU have a Trusted Connection, but the Windows Service may not.
How will I know if there's a problem?
Test, Test, Test! First, Run Locally to make sure everything works. Then put it in a Service and run that. Do you get the same results? If not, troubleshoot and find a solution. You can look in the Logs sub-folder of the installation folder and you will find System Logs that each Postmaster creates as it runs. Another easy way to determine if it is truly a User Rights issue is to do this:
1.IF Everything is working when you Run Locally but NOT when running as a service.
2.Open up the Windows Services (you can click the 
button on the services toolbar).
3.In the Windows Services Snap-in, select the CORE HL7 Postmaster Windows Service which is running your Postmaster.
4.Right-Click on that Service, go to Properties and configure that service to RUN under YOUR Login ID. This is JUST for testing purposes, you will want to undo this afterward.
5.Start the Service up. Does it work now? If so, you have identified that the issue is DEFINITELY User Rights. If NOT, Contact Customer Service for assistance.
Another important thing to remember is the System Requirements. They apply to ALL of the CORE HL7 Postmaster system. This includes the Configuration Program (the windows desktop program where you create your Postmaster profiles) as WELL AS the 4 different Windows Service exe files.
How do I address the issues?
IF you are using Network shared folders we provide a FREE easy to implement solution which you can use. Instead of sharing folders so that the Postmaster will access them via Folder Data Sources, consider creating an IPSec Tunnel Listener data source instead. Then you can use our FREE CORE HL7 IPSec Sender software on each of the remote servers to deliver HL7 messages to your postmaster over a secure point-to-point encrypted tunnel. You can download the free CORE HL7 IPSec Sender software from it's online help HERE. All Postmaster licenses allow you to create as many IPSec Tunnel Listener data sources as you like.
The solution depends on the issue of course. One common solution that customers use is to have their Network Admin create a special domain user ID which has all of the necessary rights and then configure each of the CORE HL7 Postmaster services to run as that user ID.
If the problem is Network Shared folders, try to use Local Folders on the same computer HDD that the Postmaster software is running on. IF you need to get HL7 messages from Server A to Server B you can use HL7 TCP/IP Listeners and TCP/IP Senders to transfer messages between servers.
If the problem is accessing a CORE MS SQL Schema database configure your Database Connectors (and MS SQL Server) to use MS SQL Security and use THAT instead of the Windows Trusted Connection.
