Posts

Positive Pay File Creation (CB170)

Positive Pay File Creation (CB170) produces a flat file containing bank required payment information for issued, voided and stop paid payment transactions that have been processed since the last run of the CB170 for the cash code and transaction code.

NOTE: The first time the CB170 is run for a cash code, it will only report on open transactions.

The positive pay file is then sent to the bank to be used to confirm checks presented for payment have not been altered.

Since there are no standard file layouts, you will need to use an external mapping tool to reformat the file into the specific bank format. Use this procedure to define a positive pay file.

  1. Access Positive Pay File Creation (CB170)
  2. Consider the following fields.
    • Cash Code – Enter or select the cash code for which the report is being run. Enter or select one of Cash Code, Cash Code Group, or Cash Code List.
    • Cash Code Group – Enter or select the cash code group for which the report is being run. Enter or select one of Cash Code, Cash Code Group, or Cash Code List.
    • Cash Code List – Enter or select the cash code list for which the report is being run. Enter or select one of Cash Code, Cash Code Group, or Cash Code List.
    • Transaction Code – Enter or select the transaction code for which the report is being run.
    • Report Option – Select Full Detail or Summary print option.
    • Filename – Enter a name for the positive pay file. If this field is left blank, the report creates a file named CB170POSPAY.

WebSphere Admin Console only shows WAS_HOME directory when browsing WAR/EAR files using “Remote File system”

Problem:

WebSphere Admin Console only shows WAS_HOME directory when browsing WAR/EAR files using “Remote File system”

 

Resolution:

This change is due to following Security Bulletin from IBM:

 

https://www.ibm.com/support/pages/security-bulletin-information-disclosure-websphere-application-server-cve-2017-1743

 

To get access to all directories, please add custom properties “com.ibm.ws.management.fileservice.allAccess” and “com.ibm.ws.console.webserver.anypath” property to “true” on Deployment Manager and the Node Agents.

 

In the WAS admin console,

 

Go to System administration –> Deployment manager –> Java and Process Management –> Process definition –> Java Virtual Machine –> Custom properties

 

Click the New button and enter the following:

Name: com.ibm.ws.management.fileservice.allAccess

Value : true

Click the New button and enter the following:

Name: com.ibm.ws.console.webserver.anypath

Value : true

 

Click Apply, then Save your changes to the master configuration.

 

Go to System administration –> Node Agents –> node_name –> Java and Process Management –> Process definition –> Java Virtual Machine –> Custom properties

 

Click the New button and enter the following:

Name: com.ibm.ws.management.fileservice.allAccess

Value : true

Click the New button and enter the following:

Name: com.ibm.ws.console.webserver.anypath

Value : true

 

Click Apply, then Save your changes to the master configuration.

 

Restart all the WebSphere services after setting the properties.

 

 

LSF and LMK: Enabling security_authen.log debug logging

Follow the steps below to enable security_authen.log tracing on the Lawson System Foundation (LSF) server.

 

  1. Back up the original SecurityLoggerConfiguration.xml file in LAWDIR/system.

 

  1. Edit the file and change the loglevel and tracelevel values to 7 for the SecurityAuthenFilter, as shown below:

 

<filter name=”SecurityAuthenFilter” enabled=”true” classname=”com.lawson.common.util.logging.SimpleMessageFilter”>

<parameters>

<Parameter value=”loglevel=7″/>

<Parameter value=”tracelevel=7″/>

</parameters>

</filter>

 

  1. Check the LAWDIR/system/configuration.properties file. If it does not have the following lines in the file, add them to the end of it:

 

ReloadFiles=TRUE

RefreshTimeOut=5

 

 

  1. If you did not have the lines in the configuration.properties file, you will need to restart WebSphere for LSF to enable that change and enable the L7 logging. After restarting, proceed to step

 

  1. If you already had the lines in the configuration.properties file, from a LID or other command line for LSF, type ssoconfig -c. Type the password when prompted. Select option 16 “Refresh Logging Configuration”.

 

  1. Wait 5 minutes, then view the security_authen.log and verify you see “L7” lines in it. If you do not see them, wait another 5 minutes, log into Infor Lawson Portal, and check the log again.

 

Configure IBM HTTP Server logs to rotate/roll daily

If the IBM HTTP Server for my Web Server logs become too large to open and take up too much disk space, configure the Web Server to roll the logs by day and size.

 

Steps to perform:

IBM HTTP Server has many logs in the Folder “<Installation_Directory>/IBM/HTTPServer/logs”.  You can customize those log files such as the following logs in IBM HTTP Server:

  • Admin Log: admin_access.log
  • Admin Error Log: admin_error.log
  • Access Log: access_log
  • Error Log: error_log

 

  1. Go to the location of your IBM HTTPServer installation ($IHS_HOME or <Installation_DIR>/IBMHTTPServer).
  2. Change to the “conf” directory and open the httpd.conf file.
  3. Locate the line: CustomLog log/access_log common.
  4. Comment out that line, and after it add this line:

 

Change:

CustomLog “|/opt/IBM/HTTPServer/bin/rotatelog -l /opt/IBM/HTTPServer/log/access_log.%Y.%m.%d 5M” common

 

To:

#CustomLog log/access_log common

CustomLog “|/opt/IBM/HTTPServer/bin/rotatelog -l /opt/IBM/HTTPServer/log/access_log.%Y.%m.%d 5M” common

 

  1. Locate the Line: ErrorLog log/error_log.
  2. Comment out that line, and after it add this line:

 

Change:

ErrorLog “|/opt/IBM/HTTPServer/bin/rotatelog -l /opt/IBM/HTTPServer/log/error_log.%Y.%m.%d 5M”

 

To:

# ErrorLog log/error_log

ErrorLog “|/opt/IBM/HTTPServer/bin/rotatelog -l /opt/IBM/HTTPServer/log/error_log.%Y.%m.%d 5M”

 

  1. Then restart IBM HTTPServer.

 

Review the logs in the “<Installation_Directory>/IBM/HTTPServer/logs” directory to see the access log is logging by the Current date.

 

ISS: Java out of memory error when rebuilding the search index

At times, you may get the following errors rebuilding the search index for Infor Security Services (ISS):

JVMDUMP039I Processing dump event “systhrow”, detail “java\lang\OutOfMemoryError” at 2023/03/25 19:35:53 – please wait.

 

To resolve these errors, do the following:

Adjust the JVM max memory size for ssoconfig in the GENDIR\java\command\ssoconfig.properties to 4096m

Before: ljx.vm.options=-Xmx512m

After: ljx.vm.options=-Xmx4096m

Next, save and close the file

This change is dynamic and does not require a restart, but you must exit ssoconfig for it to take effect.

After the change is completed and you’ve exited from the ssoconfig menu, you can now go back into ssoconfig -c  to choose the rebuild the search index.

How to adjust the Maximum Heap Size of a Node in Landmark Grid

To adjust the maximum heap size of a node in Landmark Grid, you first need to be logged into the Grid Management Console. From there, follow these steps:

  1. Click the Configuration Manager link  (the gears icon located at top right corner).
  2. Next, click “Applications”.
  3. Select your Landmark deployed application.
  4. Click “Edit Properties”.
  5. Under Grid Defined Properties,  click “Max Heap”.
  6. Select the “All” Radio Button.
  7. Find the node you wish to adjust, and click on value it is currently assigned.
  8. In the popup window, enter a new value and click save.
  9. In the top left corner of the screen, click save again to apply the changes.
  10. Click the home link in top right corner.
  11. Click the stop link (black box in top right corner of the node you adjusted)
  12. The system will shutdown that JVM then, automatically restart it for your change to take affect.

And you’re done. Good luck!

ISS: How To Clear a Sync Lock

To clear an existing sync lock in order to rerun the sync from the beginning again

From ssoconfig -c:

Login to the Infor Security Services web page

On the menu bar navigate to Federation > Manage Locked Process

If there is a process listed, make a note of the process that is locked

From the command line, run the ssoconfig utility. Type ssoconfig -c

At the prompt, enter the ssoconfig password

Select Manage Locked Processes

Select the number of the process that needs to be unlocked

Once it has been cleared, a message will appear that the process has been cancelled

Select the number that corresponds to Exit to return to the ssoconfig menu

Select EXIT at the ssoconfig utility

From the ISS web page:

Login to the Infor Security Services web page

On the menu bar navigate to Federation > Manage Locked Process

If there is a process listed, kindly check the box and hit the “unlock” button (Note: There may be more than one locked process, but you only need one to unlock, and all will be unlocked).

 

ISS: How to review logs after running an Infor Security Services (ISS) sync

You will want to start by reviewing the security_provisioning.log(s) in your LAWDIR/system directory.

 

All transactions completed in ISS related to user maintenance, federation, and synchronization, are logged in the LAWDIR/system/security_provisioning.log(s).

Please note, the log may take a few minutes to complete after the sync completes in the browser. Once the logs have completed, best practice is to copy the log(s) to a new directory so that they are not overwritten while you are researching the sync errors.

Open the most recent provisioning log and go to the bottom of the log. If nothing has been done in ISS since the sync completed you should see a message similar to the one below followed by a list of records that failed:
Thu Apr 26 16:56:01.282 CDT 2018 – default-457261151: Sync Analysis for object type IDENTITY completed with status=true
Thu Apr 26 16:56:01.282 CDT 2018 – default-457261151: Sync Analysis successfully completed for object type IDENTITY
Thu Apr 26 16:58:52.073 CDT 2018 – 1360326122: Sync Execution successfully completed for Task ID[4,963] with failed transactions for Sync Records:

The list of records that failed is limited to one section of the sync. You will see a list of either roles, actors, services, domains, endpoints endpoint groups or identities, depending on which section of the sync had failed records. This is because once the sync completes the analysis or execution of the section with the failed records the sync process will not continue. You must address the failed records to continue the sync.

Alternately you can search the log for the word “completed” to find the most recent section of the sync process that completed. There will be a completed message for each section of the sync.

 

Examples of completed messages without failed records:

Thu Jan 28 10:50:29.536 GMT-06:00 2021 – default-1845137754 – L(4) : Sync Execution task for [ROLE] with Task ID [1207] started.
Thu Jan 28 10:50:29.536 GMT-06:00 2021 – default-1504145202 – L(4) : Setting progress percentage [-1]
Thu Jan 28 10:50:29.537 GMT-06:00 2021 – default-1504145202 – L(4) : Success updating task [1207]
Thu Jan 28 10:50:29.537 GMT-06:00 2021 – default-1504145202 – L(4) : Starting Sync Execution using pagesize [500] and Nthread [5]
Thu Jan 28 10:50:29.551 GMT-06:00 2021 – default-1504145202 – L(4) : Retrieved 0 ROLE for execution
Thu Jan 28 10:50:29.551 GMT-06:00 2021 – default-1504145202 – L(4) : Sync Execution Successful for ROLE
Thu Jan 28 10:50:29.551 GMT-06:00 2021 – default-1504145202 – L(4) : SyncExecution execution time for [ROLE] took [0] seconds to complete

Thu Jan 28 10:55:33.485 GMT-06:00 2021 – default-863748063 – L(4) : Sync Execution task for [DOMAIN] with Task ID [1219] started.
Thu Jan 28 10:55:33.500 GMT-06:00 2021 – default-1293059945 – L(4) : Setting progress percentage [-1]
Thu Jan 28 10:55:33.500 GMT-06:00 2021 – default-1293059945 – L(4) : Success updating task [1219]
Thu Jan 28 10:55:33.502 GMT-06:00 2021 – default-1293059945 – L(4) : Starting Sync Execution using pagesize [500] and Nthread [5]
Thu Jan 28 10:55:33.506 GMT-06:00 2021 – default-1293059945 – L(4) : Retrieved 0 DOMAIN for execution
Thu Jan 28 10:55:33.506 GMT-06:00 2021 – default-1293059945 – L(4) : Sync Execution Successful for DOMAIN
Thu Jan 28 10:55:33.506 GMT-06:00 2021 – default-1293059945 – L(4) : SyncExecution execution time for [DOMAIN] took [0] seconds to complete

 

Examples of completed messages with failed records:

Thu Jan 4 07:19:55.755 EST 2018 – default- 2123289590: SyncAnalysis for ACTOR have 2 error records
Thu Jan 4 07:19:55.755 EST 2018 – default- 2123289590: Sync Analysis for object type ACTOR completed with status=true
Thu Jan 4 07:19:55.842 EST 2018 – 2123289590: Sync Analysis completed for object type ACTOR with failed Sync Records:
ACTOR=user1;
ACTOR=user2;

Tue Apr 19 10:18:33.128 CDT 2018 – default-1441714547: SyncAnalysis for ENDPOINT have 7 error records
Tue Apr 19 10:18:33.128 CDT 2018 – default-1441714547: Sync Analysis for object type ENDPOINT completed with status=true
Tue Apr 19 10:18:33.130 CDT 2018 – 1441714547: Sync Analysis completed for object type ENDPOINT with failed Sync Records:
HTTPPORT=82,SSODOMAIN=CSEMSS_EXTERNAL,FQDN=WFHPROD-LSF01.COM,HTTPSPORT=1448;
HTTPPORT=81,SSODOMAIN=CS_INTERNAL,FQDN=WFHPROD-LSF01.COM,HTTPSPORT=443;
HTTPPORT=81,SSODOMAIN=CS_INTERNAL,FQDN=WFHPROD-LM01.COM,HTTPSPORT=1443;
HTTPPORT=85,SSODOMAIN=TC_LDAP_BIN_EXT,FQDN=WFHPROD-LSF01.COM,HTTPSPORT=1447;
HTTPPORT=85,SSODOMAIN=TC_LDAP_BIN_EXT,FQDN=WFHPROD-LM01.COM,HTTPSPORT=1447;
HTTPPORT=9080,SSODOMAIN=CS_INTERNAL,FQDN=WFHPROD-MSCM01.COM,HTTPSPORT=8443;
HTTPPORT=21442,SSODOMAIN=CS_INTERNAL,FQDN=WFHPROD-IES01.COM,HTTPSPORT=9443;

Tue Apr 3 10:51:21.774 EDT 2018 – default-471380075: SyncAnalysis for IDENTITY have 4 error records
Tue Apr 3 10:51:21.774 EDT 2018 – default-471380075: Sync Analysis for object type IDENTITY completed with status=true
Tue Apr 3 10:51:21.774 EDT 2018 – 471380075: Sync Analysis completed for object type IDENTITY with failed Sync Records:
IDENTITY=USER:DOMAIN\user1,SERVICE=SSOP,ID=user1;
IDENTITY=USER:DOMAIN\user2,SERVICE=SSOP,ID=user2;
IDENTITY=USER:[email protected],SERVICE=THICKCLIENTLDAPLS,ID=user1;
IDENTITY=USER:[email protected],SERVICE=THICKCLIENTLDAPLS,ID=user2;

To find the exceptions for the failed records you will need to search within the log(s) each failed record. For each failed record you will search for the value from the list without the semicolon at the end of the line:
For failed record ACTOR=user1; you will would search for “ACTOR=user1”
For failed record HTTPPORT=82,SSODOMAIN=CSEMSS_EXTERNAL,FQDN=WFHPROD-LSF01.COM,HTTPSPORT=1448; you would search for “HTTPPORT=82,SSODOMAIN=CSEMSS_EXTERNAL,FQDN=WFHPROD-LSF01.COM,HTTPSPORT=1448”
For failed record IDENTITY=USER:DOMAIN\user1,SERVICE=SSOP,ID=user1; you would search for “IDENTITY=USER:DOMAIN\user1,SERVICE=SSOP,ID=user1”

 

Searching on user information via the Infor Security Services (ISS)

Search results are incorrect for user/resource information via the Infor Security Services (ISS).

However, the user search is correct in Lawson Security Administrator (LSA) tool and Infor Rich Client (IRC).

Search results in ISS are returned from a search index, not directly from LDAP as is the case with LSA or the GEN database as is the case with IRC. The search index may not be updated if changes are made outside of ISS. Changes made directly in IRC will NOT update the search index.

To resolve the issue, you need to rebuild the search index that ISS uses using ssoconfig.

Open Lawson Interface Desktop (LID) and connect to the Lawson System Foundation (LSF) server or from a command line with environment variables set:

Type ssoconfig -c and press enter

Enter your password for ssoconfig

Choose the option for Manage Search Index and press enter.

Choose the option for Build Resources Full Index and press enter.

This part can take a while, how long depends on the number of resource, identity, and service records in LDAP. You can monitor the progress of the rebuild in the LAWDIR/system/security_search.log

Wait for the menu options to come back and then choose Build Monitoring Full index.

When the menu comes back to where you can choose the build options again the rebuild has completed and you can try your search in ISS again.

Either way you rebuild the index, you can verify that the rebuild is complete by verifying the following in the LAWDIR/system/security_search.log:

Tue Mar 13 22:47:01.006 CDT 2018 – default-434727101: Done indexing identities

Tue Mar 13 22:47:01.007 CDT 2018 – default-434727101: Closing index…

Tue Mar 13 22:47:01.037 CDT 2018 – default-434727101: Activating index…

Tue Mar 13 22:47:01.038 CDT 2018 – default-434727101: Index activated

Tue Mar 13 22:47:04.073 CDT 2018 – default-434727101: Finished indexing

 

ISS: How to research and resolve IDENTITY record failures in the sync

For errors related to the failed IDENTITY records from an ISS sync follow these steps:

Determine which system, Lawson System Foundation (LSF) or Landmark (LMK), the identity record failed in:

After finding the exception in the log, scroll up in the log until you see a message such as this:

Getting resource from INFORBCLM01.INFORBC.COM;9906;9907;LANDMARK

or

Getting resource from INFORBCLS01.INFORBC.COM;6626;6627;LSS

or

Processing record #4,996 of LSF

or

Processing record #4,986 of LANDMARK

Messages that reference LSS or LSF indicate the issue is in LSF and the record should be reviewed in that system. Messages that reference LANDMARK indicate the issue is in LMK and the record should be reviewed in that system.