Archive for category: Articles

You are here: / / Articles

Should Users CheckLS be set to Yes in v10 Lawson?

, ,

As a Lawson Managed Service provider, we see many different Lawson v10 systems (even v9 systems) and often we find users with CheckLS = No but get asked if this should be set to Yes.

In the past when migrating clients from LAUA to v9 or v10, CheckLS to Yes would put them on v9 or v10 security instead of LAUA security.

 

Today if you’re on later versions of v10, it’s still the best practice to set CheckLS to Yes in the users RM info but the official Infor documentation reads as follows:

“When you upgrade to 10.0.x, the system will treat this field (checkLS) as set to Yes in all cases”

 

So if you’re scratching your head, what this means is that in v10 and forward, checkLS field Yes or No still puts you on v10 Security. However, setting it to Yes can also give users the ability to access LID if needed (assuming they have ENV access to specific LID command tokens).

 

BATCH Privileged user password expiration

, ,

The BATCH privileged user will only be used for standard Lawson batch programs. If the LSF environment is configured to use the BATCH privileged user and a batch job executes a user token with a script goes into “Needs recovery” status with the error: “execjob(laStartProcess): Unable to log in DOMAIN\USERNAME StartStep failed: Overlapped I/O operation is in progress”, then its possible that the users password has been changed or expired on the network.

 

The user’s password for their environment identity found in Lawson Security under User Management MUST match the user’s domain/network/AD password. This is required by user tokens. To resolve this issue so user tokens run to completion, the Lawson Security Administrator will need to update the environment identity password for the user running the job so it matches their OS/AD password, OR the system would need to be configured so the user could enter their own password so it matches their OS/AD password.

Lawson Security Administrator: Data area has been suspended

, ,

There may be an instance when you are getting an error in Lawson Security Administrator (LSA) stating that the “Data area has been suspended”. This happens when you are adding a rule to a security class. This error usually occurs after running dbreorg without stopping your LSF WebSphere Application Server prior to the execution of dbreorg.

To resolve this issue, follow the steps below:

  1. Stop LSF WebSphere Application Server
  2. Stop LSF WebSphere Node Agent
  3. Stop LSF WebSphere Deployment Manager
  4. Make sure that there are no java processes
  5. Stop your LSF environment
  6. Start LSF WebSphere Deployment Manager
  7. Start LSF WebSphere Node Agent
  8. Start LSF WebSphere Application Server
  9. Start your LSF environment

Lawson Security Administrator Cached URLs

, ,

There may be a time when you want to remove a URL from the cached URLs list in Lawson Security Administrator (LSA).  This could help clear storage space and run your programs faster and would not hurt to clear your cache regularly.

If you want to clear your LSA cached URLs, on your desktop where you use the program, you will need navigate to %programdata%/LawsonHttpClient.  Next, edit the list as needed and save it. The changes will be immediate after you click save. Your LSA URLs have now been cached! You can refer to the screenshots below for a visual guide.

 

Lawson job stuck in submitting status

, ,

Is your Lawson job stuck in a submitting status after clicking submit multiple times as shown below?

This commonly happens when a user returns to an organization and their access is restored or another users lawson jobs are copied over to this user. These jobs have been updated from CTPs or patches and may have old or corrupt parameters.

 

Resolution 1:

Try and simply create a new job in Lawson (deleting the old) and try submitting again. This is assuming the user’s security and identity are already setup correctly.

 

Resolution 2:

If the above doesn’t resolve the issue, the cause of the issue can occur when the users DOMAIN Identity is corrupt or out of sync in LDAP. This is the domain identity that controls the print directory found in “Managed Identities” when viewing a user in Lawson Security.

 

First backup the users print directory and do a jobdump command in LID to copy their jobs. The delete and re-add this DOMAIN identity to see if it resolves the issue.

 

If it doesn’t, you’ll need to delete the user completely and re-add them into Lawson. This can be done with the Lawson Security Admin tool. You can also download Jxplorer and see if LDAP is holding onto the identity (backup LDAP before editing/deleting any identities in Jxplorer).

 

Good luck!

Set debug logging on Lawson Security Rules

, ,

Follow the steps below to set debug logging on Lawson Security Rules.

 

Launch Lawson Security Administrator (LSA).

Select Server Management.

Select Server.

Select the Auditing + Logging tab.

Under Logging Levels on the right, click Debug.

Under the Select User to Log section type in the RMId of a user who should be logged.

Additionally, under the Select User to Log section type ALL in upper case*.

Click Apply.

After the security Caching Interval time is reached then perform the same action you need to troubleshoot.  Note the date/time you perform the action.

Collect the logs: On the Lawson server, the name and location of the log files are: LAWDIR/system/lase_server_*_*.log  and ios.log and ios.log(x).

To disable the debug logging in LSA, go back to the Auditing + Logging tab. Change the Logging Levels to Critical and highlight the RMId you added and click Remove, then highlight ALL and click Remove.

Lawson Error – Ask your administrator for access to other applications

, ,

A user logs into Infor OS or Lawson Mingle, clicks the waffle icon in the top left and encounters the below error:

“If you’re seeing this, ask your administrator to give you access to other applications”

 

Resolution 1 (Requires a Lawson Administrator):

Verify if the IFSSecurityRole has been assigned to the Application:

  1. In Infor OS, click on the User Menu and go to Admin Settings
  2. Within the “Manage Applications” section, double-click on the Application that the user is attempting to use (e.g., Infor Lawson).
  3. In the Application Details screen, choose the Permissions tab

On the Permission screen, you should see the IFSSecurityRoles configured for the application.

To grant permission to the user for the application, ensure that at least one of the listed IFSSecurityRoles is assigned to them.

 

Resolution 2 (Requires a Lawson Administrator):

Provide User Permission:

  1. Access the User Menu and navigate to User Management.
  2. In the Search field, search for the user
  3. After the user’s details appear in the search results, click on the User Details icon.
  4. On the user screen, proceed to the Security Roles tab.
  5. Click the plus sign in the upper left corner, choose the appropriate IFSSecurityRole, and click on ADD & CLOSE to grant permission.

Have the user sign out and sign back in to Infor OS after the change.

 

Updating Infor RQC Configuration

, ,

If you make changes to the rqc_config.xml file, you will need to deploy the changes to RQC. Luckily, this is a simple change.

To update or make changes to RQC, follow these steps:

Either go to http(s):/<lawson server>:<port>/rqc/html/utility.htm

OR

Open Lawson portal and navigate to Bookmarks > Requisition Center > Utilities. They both will lead you to the next screen where you will have a couple options.

By clicking “Reload Configuration File”, this will deploy your changes to rqc_config.xml. And by clicking “RQC IOS Cache Refresh”, this will refresh the RQC cache. See the screenshots below for reference. Your rqc_config.xml file is now successfully updated.