I ran across an error while doing some testing with Session Integrator in a distributed deployment scenario. By “distributed deployment”, I am referring to a deployment where you have a Session Integrator application running on a system that does not host the 3270 or LUA LUs that the application is using to communicate with the mainframe. The LUs are defined on another HIS Server system which is also the system where the Session Integrator Server service is running that the SI application will be using. The following is an example of the 2 server deployment scenario:
Application Server
- HIS 2013 Server
- Configured with a Role of Secondary Configuration Server or Use Remote SNA Gateway
- Session Integrator application
HIS Server (SNA Gateway)
- HIS 2013 Server
- Configured with a Role of Primary Configuration Server
- This HIS 2013 Server doesn’t have to be the Primary Configuration Server if there are other HIS Servers in the HIS Subdomain, but it is for this example.
- Host connection(s) to the IBM mainframe
- LUs (either 3270 or LUA, depending on what you use in your environment) that the SI application will use to communicate with the mainframe application.
- Configured with a Role of Primary Configuration Server
In this sample deployment, the SI application running on the Application Server uses the Session Integrator Client (SI Proxy) components of the Session Integrator feature to communicate with the Session Integrator Server service that us running on the backend HIS 2013 Server that hosts the LU(s) used to communicate with the mainframe application.
When I setup this type of environment and ran the LU0NET Session Integrator application included in the HIS 2013 SDK, the following error was displayed:
I knew for a fact that the LU that I was trying to connect to was available, so I started into normal troubleshooting to see what might be happening. Since Session Integrator uses DCOM to communicate between the Session Integrator Client and Session Integrator Server components, my first thought was that this might be happening due to a permission issue such as what I described in my Why does Session Integrator log Event ID 6 and Event ID 24 warnings? blog post. It turns out that this was not the cause of the problem. My next step was to enable Session Integrator Client traces via the HIS Trace Utility (histrace.exe) to see what might be happening. After I reproduced the problem with the traces enabled, I took a look at the Session Integrator Client internal (sicint1.atf) trace and I found the following trace statements when the SI Client was trying to connect to the SI Server service:
Try to create server object on SJACKHIS20131
Got handle 1ae66418 from server
Client providing cookie 0xa0a0a0a1
Failed to create session on SJACKHIS20131, hr = 800706ba
The 800706ba return code indicates RPC_S_SERVER_UNAVAILABLE. This indicated to me that the remote server where the SI Server service was running was not listening or not allowing communication over the network protocol/port being used. Therefore, I captured a network trace of the problem using Network Monitor to see what was happening on the network. What I found was that the Application Server was sending a TCP/IP Syn request to the remote HIS 2013 Server, but no response was being received. The Syn request was resent two additional times per the default TCP/IP retry behavior and then the connection attempt failed. This resulted in the error being displayed by the SI application.
This behavior led me to looking at the Windows Firewall settings on the two HIS 2013 Server systems.
First, I went to the HIS 2013 Server where the SI Server service was being used. The HIS specific firewall rules were enabled, but HIS doesn’t create a specific rule for the Session Integrator Server service. I decided to manually create an Inbound Rule for SIServer.exe (Session Integrator Server service) to allow TCP traffic over all ports to the HIS 2013 Server system to see if that would correct the problem.
Second, I went to the Application Server to modify the Windows Firewall settings to allow the Firewall to “Display a notification” when the firewall blocks a program from receiving inbound connections as shown here:
I did this just to see if I would see any messages when running the SI application.
After making these changes on the two servers, I ran the SI application again. The firewall on the Application Server displayed a popup message when I ran the SI application (LogonScriptClient.exe in this case) as shown here:
After clicking Allow access, the firewall adds two new inbound rules (one for TCP traffic and one for UDP traffic) for this application.
After enabling the new firewall rules, the SI application was able to connect to the SI Server service and it was able to connect to the mainframe application using the LU that was specified in the SI application configuration.
The summary is that to allow this type of Session Integrator distributed deployment to work, you may need to do the following depending on your firewall settings in your environment:
- Setup a firewall rule for the Session Integrator Server service to allow incoming TCP traffic from Session Integrator Clients that are running SI applications in the network.
- Setup firewall rules for the SI application on the Application Server to allow incoming connections for the application.
If the Session Integrator application and the Session Integrator Server service are running under different user accounts, then you may also need to setup the DCOM permissions as outline in the other blog post I referenced above.