Overtime the LSF Lawson directory builds up and may even cause performance issues given the amount of data that may need to be backed up every night. Below are some steps you can take to help analyze and clean up your LSF Lawson directory.

 

  1. Download and Install the free WinDirStat tool found at https://windirstat.net/
  2. Once you open the tool, select and run it for your local LSF directory:
  3. You may notice right away that 3 directories stand out:
    1. %LAWDIR%\print
    2. %LAWDIR%\work
    3. %LAWDIR%\system\joblog


These directories will fill up overtime as users run batch jobs/reports.

  1. To clean up the work directory, you can expand the directory in Windirstat and manually get rid of large files, outdated reports and files.
  2. For cleaning up the print and joblog directory, Lawson has a utility called deljobhst
    1. To get a more in-depth look at the deljobhst utility see here
    2. NOTE: It is recommended to backup these directories especially if your organization has a retention policy.
  3. Open LID and connect to the environment you want to clean up.
  4. We personally are going to delete all printed reports and joblogs that are over 400 days old.
  5. convertunits.com can help determine what the date is 400 days from today is.
    1. In our case, it is November 26, 2019
  6. In LID, we would run: deljobhst -crj 112619
    1. This would remove all completed jobs (c)
    2. All generated print files associated with batch jobs (r)
    3. All recurring job entries (j)
  7. After this completes, if Windirstat is still open, click the refresh all button:

This type of work is typically done by a Lawson technical resource. Organizations often hire a Lawson consultant team who offer managed services at a fixed monthly rate. These Lawson teams have a wider range of expertise and knowledge and are ideal for larger organizations but also are great for smaller ones that don’t need a dedicated Lawson employee on-site. Nogalis does offer this as a service so feel free to reach out to us via our contact page. We typically provide the work above in a monthly or bi-monthly healthcheck that also captures several other key data points to stay proactive with your system before a problem occurs. Hopefully this was helpful!

Description:

When I try to access user information in LSA security administrator, I am not able to see any users.

The error edit shows:

Stack Trace : org.mozilla.javascript.EcmaError: ReferenceError: “MISSING” is not defined. (<RuleAttribute>#1)
at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3226)
at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3216)
at org.mozilla.javascript.ScriptRuntime.notFoundError(ScriptRuntime.java:3289)
at org.mozilla.javascript.ScriptRuntime.nameOrFunction(ScriptRuntime.java:1633)
at org.mozilla.javascript.ScriptRuntime.name(ScriptRuntime.java:1572)
at org.mozilla.javascript.gen.c221._c0(<RuleAttribute>:1)
at org.mozilla.javascript.gen.c221.call(<RuleAttribute>)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:337)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:2755)
at org.mozilla.javascript.gen.c221.call(<RuleAttribute>)
at org.mozilla.javascript.gen.c221.exec(<RuleAttribute>)
at com.lawson.lawsec.author.mgr.Rule.exec(Rule.java:168)

Resolution:

This message tells us that for some reason the security server (LASE process that runs) lost its connection to the ldap instance where the rules are stored for Lawson Security.

To work toward resolving the issue, you can follow KB Article ID: 1580306 – “Lawson Security: How to run a User Security Report when requested by Support”, for the application profile in question. Within that report, look for the word MISSING on the right hand side of the report where the ruleText is listed.
Most of the time, when this error is presented, you can use the Lawson Security Administrator (LSA) tool to fix the issue without doing a full restart of the Lawson related services.

If you do see the word MISSING, do the following from within the LSA tool:

  1. Click on “Server Management”
  2. Click on “Clear Cache”
  3. Go open a brand new IE browser session.. do not use a new TAB in an existing browser, it has to be a “new IE session”
  4. Log into Infor Lawson for Portal for Ming.leas someone that is a “Portal Administrator” that can run the “Clear IOS Cache” option.
  5. Ask one of the users to open a new IE session, not a new TAB within an existing browser, then try their same action that they were having an issue with.

ADDITIONAL INFORMATION:  In regard to the difference between the function of the “caching interval” setting and using/clicking the “Clear Cache” option under Server management. When you make security changes to users, you should not need to hit clear cache after making a change.  When the caching interval time is hit, the change will be placed into the security cache for use. The difference here is that when you hit the “Clear Cache” option, it drops the full security cache and re-reads the entire cache instead of reflecting just the changes. So, in order to clear up the issue where the security process could not find the rule Id tied to the securable objects, you needed to click on “Clear Cache”.

In some severe instances we may need to have the some of the rules deleted and rewritten but that is not a common occurrence and there are other steps we’d need to do prior to having you delete and rewrite rules so please open a new support incident if the steps above do not fix the issue.

 

You may run into this error at some point in GL40.1:

Fortunately, there’s an easy fix to this. First login to Lawson portal and search GLMONITOR:

In GLMONITOR, type in GL190 and hit Inquire, if you get results and notice the run time, the process is in fact still running and causing the issue with GL40:

Go to job scheduler by opening LID and typing in jobschd >> F7 + A to select all users >> Then W to go to waiting screen.

Look for any GL190 jobs running and verify the User Name is the same one in GLMONITOR when inquiring on GL190 program. Check the error and if its safe to recover, recover it and let the job complete.

 

Go back to GLMonitor and inquire on GL190 to verify the job is no longer running:

 

Go to GL40.1 and release your Journal Entries.  Good luck!

 

This type of work is typically done by a Lawson functional resource. Organizations often hire a Lawson consultant team who offer managed services at a fixed monthly rate. These Lawson teams have a wider range of expertise and knowledge and are ideal for larger organizations but also are great for smaller ones that don’t need a dedicated Lawson employee on-site. Nogalis does offer this as a service so feel free to reach out to us via our contact page.

 

If you ever come across an instance where you need to clean up your system from old or faulty data, you can use the loadusers utility to mass-delete users, roles, or groups. The loadusers utility accepts input from an XML file that you create. You can simply populate any attributes that you want to delete.

The following is an example of an XML file from the Infor LSF Documentation guide that has been used to delete users, roles, and groups. The roles and groups in this file would only be deleted if they were not assigned to any other users than the ones being deleted.

Sample XML file

<?xml version=”1.0″ encloding=”ISO-8859-1″?<XML><ROLEDATA>    <ROLE ID=”Test1″>   <ROLE ID=”Test1″></ROLEDATA><GROUPDATA>    <GROUP ID=”Test1″>   <GROUP ID=”Test1″></GROUPDATA><USERDATA ProductLine-“APPS900″ SSOPPASSWORD=”temp”>    <USER ID=”cssttst100″/>   <USER ID=”cssttst101″/>   <USER ID=”cssttst102″/>   <USER ID=”cssttst103 RMID103″/></USERDATA><IDENTITIES></IDENTITIES></XML>

Command syntax for loadusers when used to delete users

From the command line, type

loadusers -f filename -u

where

filename = the XML file that contains the user data to be deleted

First lets login into LBI and open smart notifications:

Once open, go to Notifications Tab:

Select edit on the notification you want to modify:

Go to the Related Info >> Links >> Enter a Name and Web Address >> Add >> Save Updates:

To edit an existing related info link, simply select edit under “My Custom Urls”:

Make sure you Save Updates!

These related Info Links show up at the bottom of the report the user receives as shown below:

This type of work is typically done by a Lawson technical resource. Organizations often hire a Lawson consultant team who offer managed services at a fixed monthly rate. These Lawson teams have a wider range of expertise and knowledge and are ideal for larger organizations but also are great for smaller ones that don’t need a dedicated Lawson employee on-site. Nogalis does offer this as a service so feel free to reach out to us via our contact page.

When making a change via the Lawson Security Administrator (LSA) tool like adding or removing a role for example, saving the changes make get an error saying it cannot make the change.

 

“Unable to change object(RMidValue), change failed. Original Exception: null”

 

How can I resolve this?

 

Steps To Reproduce:

 

Duplicate this in a “Federated” setup, Lawson System Foundation (LSF) is federated with Landmark

 

You would need to have a lock situation with the write.lock file for the Infor Security Services (ISS) Search index (Lucene Index), example message from the LAWDIR/system/security_search.log:

 

org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/lsfprod1/law/system/search/index/resource/DEFAULT/index_2/write.lock

 

 

 

at org.apache.lucene.store.Lock.obtain(Lock.java:84)

 

at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1060)

 

at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:882)

 

at com.lawson.lawsec.search.lucene.LuceneIndexManager.<init>(LuceneIndexManager.java:45)

 

at com.lawson.lawsec.search.lucene.IndexWriterRegistry.initForTenant(IndexWriterRegistry.java:131)

 

at com.lawson.lawsec.search.lucene.IndexWriterRegistry.lookup(IndexWriterRegistry.java:196)

 

at com.lawson.lawsec.search.lucene.LuceneIndexServiceFactory.createLucenenServiceForRM(LuceneIndexServiceFactory.java:69)

 

at com.lawson.lawsec.search.lucene.LuceneIndexServiceFactory.createIndexServiceForRM(LuceneIndexServiceFactory.java:34)

 

at com.lawson.lawrm.search.RMIndexManager.updateIndex(RMIndexManager.java:244)

 

at com.lawson.lawsec.server.events.ServerRMDataAccessEvent.processRMResource(ServerRMDataAccessEvent.java:699)

 

at com.lawson.lawsec.server.events.ServerRMDataAccessEvent.processRMDataEvent(ServerRMDataAccessEvent.java:173)

 

at com.lawson.lawsec.server.events.ServerRMDataAccessEvent.process(ServerRMDataAccessEvent.java:92)

 

at com.lawson.lawsec.server.SecurityEventHandler.processEvent(SecurityEventHandler.java:634)

 

at com.lawson.lawsec.server.SecurityEventHandler.run(SecurityEventHandler.java:377)

 

 

 

Log into the LSA tool

 

Go to User Management

 

Go to User Maintenance

 

Search for a user

 

Right click on the user’s record and choose “Edit RM Information”

 

double click the Role field to show the roles available and assigned

 

add or remove a role from the list and hit finish.

 

Go to the Edit menu and choose “Change”

 

You should receive the error in the status bar of the LSA tool

 

“Unable to change object(RMidValue), change failed. Original Exception: null”

 

Work Around:

 

Try rebuilding the ISS Search Index, this is not guaranteed to work;

 

ssoconfig -c

 

enter your password for ssoconfig

 

option 20 –  Manage Search Index

 

option 2   –  Build Monitoring Full Index

 

When this finishes, then next;

 

option 1   –  Build Resources Full Index

 

This step may take a while, you can monitor the status of the rebuild in the LAWDIR/system/security_search.log file. When this finishes then;

 

option 4   –  Refresh Server Index