[Brian]

Thanks for the response.
I was somewhat able to somewhat reproduce this in my test environment using 6.2 and 19.1.
First I set up a connection to my receiving interface on a remote server using port 5001. Then, on that server I created a Firewall Inbound rule to block port 5001, but left it disabled.
I connected the CL to my interface and the log file shows a connection.
While the connection is still up, I turn on the firewall rule and the CL thread goes to opening and I get this in the error log.
[pti :even:DBUG/1: test_out:10/28/2020 09:34:35] Calling cb 0x2cbdc9c0
[pdl :read:DBUG/2: test_out:10/28/2020 09:34:35] Events: E 32, R 8, W 0
[pdl :PDL :ERR /0: test_out:10/28/2020 09:34:35] read failed: Unknown error
[pdl :PDL :DBUG/0: test_out:10/28/2020 09:34:35] input buffer accepted 0 bytes, now 0
[pdl :PDL :ERR /0: test_out:10/28/2020 09:34:35] read returned error 0 (No error)

My receiving interface shows it’s still up and if I run a netstat on port 5001 on the remote server, the port is established. My CL and interface never reconnect unless I recycle the remote interface. Alerts on the CL are doing no good because the remote interface thinks it’s still connected.

I repeated the same test on my CL 19.1 server and the only difference is the log file for the read returned (ERR vs. DEBUG).
6.2 = [pdl :PDL :ERR /0: test_out:10/28/2020 09:34:35] read returned error 0 (No error)
19.1 = [pdl :PDL :DEBUG /0: test_out:10/28/2020 09:34:35] read returned error 0 (No error)

Now, the only thing that is different than 2 customer sites I’m dealing with (both at v6.2) is that their error repeats every 1 second until the remote interface is recycled.
On both my 6.2 and 19.1, I see this error 1 time and that’s it.

I’m not that familiar with networking, but is it possible a customer network is running some sort of scan that blocks ports temporarily?
And in some of my connections, the remote interface automatically recycles and others do not.

[Brian]

Yes, I opened a ticket with Infor and found out about this.

However, the path I was using for PS1 and CMD is no longer working, you now have to enter the full path. And, CMD is not working at all, but I was able to get CMD to work using the call to PS1.

Here are my notes.

Alert Issues after upgrading to Cloverleaf v19.1:

Tested with Win2012 and Win2016

Issue is that you can no longer add a CMD or PS1 EXEC to an alert without getting a “Whitelist” error. If the alert was upgraded, it will be in the alert file, but if you try to save the alert you will get the Whitelist error.

In order to add to the alert, you first must add the *.exe to the “Whitelist”.

For v19.1, it appears that only Powershell is working, CMD is not, but you can call the PS1 exe instead.

If you do not have the Whitelist configuration and run the alert, the hciMonitord.log shows error: Illegal command …. Skip it

First, find the install path for powershell.

Select the Windows Key from the taskbar> Type Powershell> Right click “Windows Powershell”. Do not select the ISE or any of the x86 versions.

Select Open file location. This will be the shortcut icon.

Right click the icon and select properties

Remember the value for “Target”. this is the path you will enter in the Whitelist configuration.

Select the Windows Key from the taskbar> Navigate to the Infor section and choose “Server Administration”

Select the tab “Command Whitelist”.

Select Add> Single command.

For the name, enter “Powershell.exe”

For the Path, Navigate to the path for the powershell.exe. IE: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe

Select OK

Select Save

Close the Server Administration

Restart the Infor Service.

 

Reonfigure the Cloverleaf Alert

Open any alert that uses the Alert Action EXEC.

Change the action to include the full path of powershell and the full path of the script file.

PS1 script:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe “&{D:\Qdx_work\Custom_Scripts\CloverleafInterfaceRecycle.ps1}”

CMD script:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe “&{D:\Qdx_work\Custom_Scripts\QdxInterfaceRecycle.cmd}”

[Brian]

Nothing has changed to the windows install. 2012 Server.

The last windows update was 3/3/20, and the CL upgrade was 4/3/20.

When I say upgrade, I first unistalled (control panel) 6.2 and rebooted.

Doesn’t appear to be related to powershell, but the EXEC command from the alert. I tried entering a path to a command file, same issue.

cmd /c D:\\Qdx_work\\custom_scripts\\QdxInterfaceRecycle.cmd

then tried the path to notepad.exe. same issue.

I do see a DB file called whitelist in the bin folder. C:\gehc-it\ccg\quovadx\cis19.1\integrator\bin\whitelist.db

When I compared this to a 6.2 server I have, I don’t have this file.

The Date/time of the file matches the CL install date.

I tried to rename the file, but the warning msg says it’s in use by the HCIaccess.exe. Stopped the monitor daemon and then was able to rename the file.

I still get the error when trying to save my alert using an EXEC command.

I closed CL GUI and then was able to rename the file to .old. Go back to CL and try to edit my alert and I get the same error, and the whitelist.db file gets created in the bin folder.

My 6.2 server (windows 2016) is still working fine and on the same domain as the Windows 2012 server with CL 19.1.

Not sure if this is a domain issue since both servers are on the same domain.

[Author]

Replies