Posts

Migrate LBI Data to a new Database Server

Whether you are refreshing your test LBI environment or moving all your data to a new database server, you may eventually need to migrate your report data for LBI. This is a relatively simple process, provided the LBI instances using the data are the exact same version and service pack level.

First, back up your LBI databases on the source server and restore to the destination server (LawsonFS, LawsonRS, LawsonSN).

If you are migrating data for one LBI instance, you just need to point your WebSphere data sources to the destination server.

If you are migrating data for a new LBI instance, or for your test environment, you’ll need to update all the services and references to the old LBI instance.  In the LawsonFS database, ENPENTRYATTR table, you’ll need to search the ATTRSTRINGVALUE column for your old server name, and replace it with the new server name.  For example,

UPDATE ENPENTRYATTR

SET ATTRSTRINGVALUE = REPLACE(ATTRSTRINGVALUE, ‘source-server’, ‘destination-server’)

WHERE ATTRSTRINGVALUE LIKE ‘%source-server%’

 

After you update those strings, you will need to redo your EFS and ERS install validators to set the correct URL.

  • http(s)://lbiserver.comany.com:port/efs/installvalidator.jsp
  • http(s)://lbiserver.comany.com:port/ers/installvalidator.jsp
  • http(s)://lbiserver.comany.com:port/lsn/admin/installvalidator.jsp

Next, log into LBI and go to Tools > Services.  Click on every service definition to look for the source server name, and update with the destination server name.

Make sure your data sources are pointing to the proper ODBC DSNs, and/or add new ODBC connections.  Test and verify all your reports.

Update ssoconfig service by loading a file

You might come across the need to update a service or identity configuration in ssoconfig (LSF), especially if you have implemented AD FS and need to update your usernames or service URLs. A quick way to update a ssoconfig service is to load an XML file with the updates. Create and save your XML file, set your environment variables on LSF, then run the command ssoconfig -l <password> <filepath>

Here is the file format for a service and an identity (make sure OVERRIDE is set to true if you are doing an update):

 

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

<BATCH_LOAD FORMAT=”” OVERRIDE=”true”>

  <SERVICE>

<HasCredential>TRUE</HasCredential>

<LoginProcedure>Form based</LoginProcedure>

<ID>DSSOIBITEST</ID>

<SvcEntryAttrList>user,password</SvcEntryAttrList>

<LOGINSCHEME NAME=”Form”>

<PROTOASSERT>Use HTTPS always</PROTOASSERT>

<HTTPURL>http://server.company.com:80/sso/SSOServlet</HTTPURL>

<HTTPSURL>https://server.company.com:443/sso/SSOServlet</HTTPSURL>

<PRIMARYTARGETLOOKUP>Verify passwords in Lawson Security</PRIMARYTARGETLOOKUP>

<LOGIN_RDN/>

<NAMING_ATTR>cn</NAMING_ATTR>

<USERNAMEFIELD>_ssoUser</USERNAMEFIELD>

<PASSWDFIELD>_ssoPass</PASSWDFIELD>

<SERVICEURL>https://server.company.com:443/sso/SSOServlet</SERVICEURL>

<LOGIN_SUBMIT_METHOD>POST</LOGIN_SUBMIT_METHOD>

</LOGINSCHEME>

<IdentityAttrList>user</IdentityAttrList>

<CredentialAttrList>PASSWORD</CredentialAttrList>

     </SERVICE>

</BATCH_LOAD>

 

<?xml version=”1.0″ encoding=”ISO-8859-1″ standalone=”no”?>

<BATCH_LOAD FORMAT=”Opaque” OVERRIDE=”TRUE”>

<IDENTITY SERVICENAME=”SSOP” >

<RDID>lawson</RDID>

<USER><![CDATA[lawson@company.com]]></USER>

</IDENTITY>

</BATCH_LOAD>

 

Convert LBI to SSL

To convert LBI to use https, the first step is to make sure that you have valid PKCS 12 certificates installed in the Personal and Trusted Root stores on your LBI server. Export your certificate (or have your system admin do it for you) with the public key and private key, and with the full certificate chain.  During the export, provide a password for the certs.

In WebSphere on your LBI server, go to Security > SSL certificate and key management.  Select Key stores and certificates > NodeDefaultKeyStore > Personal certificates. Replace the default certificate with the cert that you just exported. Do the same for the CellDefaultKeyStore (if applicable). Next, under Key stores and certificates again, select the KeyStore and TrustStore, and select “Exchange Signers…”

Add your new certificate from the KeyStore to the TrustStore and Apply. Save the changes. No need to restart your application server yet, we will do that in a bit.

Make sure that your Virtual Hosts contain an alias for the secure port you plan to use. Note that this port must be the WC_defaulthost_secure port under Ports on your Application Server.

In LSF, update your DSP service for LBI to use the new service URL. The service should be set to “Use HTTPS always” and the new service URL should be “https://lbiserver.company.com:port/sso/SSOServlet.

Restart your LSF application server and your LBI application server.

Open your LBI install validator with https://lbiserver.company.com:secureport/efs/InstallValidator and make sure the system URL is set to the new secure URL. Submit the new URL. If the certificates are not valid, you will receive an error message indicating as such. Otherwise, there should be no failed tests.

Configure LBI for ADFS

When you configure LSF for ADFS, you will need to make some changes to your LBI configuration so that users will be able to access LBI with the userPrincipalName (username@company.com).

The first thing you need to do is ensure that you have a user in Lawson security where RMID = SSOP = UPN (userPrincipalName).  The RM User that is used to search LSF for LBI users must have an account where RMID and SSOP match.  It is recommended that you have a new AD user created for this purpose (such as lbirmadmin).

Add the new user to Lawson, ensuring that their ID and SSOP values both use UPN.  (lbirmadin@company.com)  Also make sure the new user is in the appropriate LBI groups for LBI access.

The next change will take place in the sysconfig.xml file located in <LBI install directory>/FrameworkServices/conf.  The ssoRMUserid should be the UPN of your LBI user mentioned above.  After you make these changes, restart the application server, clear the IOS cache in Lawson, and try logging into LBI.

500 Error in DSP Applications

If you update your LSF core technology, and subsequently find that your SSO applications (such as LBI or MSCM) produce a 500 service error, you probably need to update your DSP install on the host server for the SSO application.  Please see our article archive for instructions on how to update and reconfigure DSP.

If you get a “NoClassFoundError”, you may need to add a new class path to your JVM properties in WebSphere.  Figure out which class is missing and add the path to the JVM properties, then restart your application server and check to see if the issue is resolved.

Web Page errors when logging into IFS

If you see some error messages when you first open IFS (similar to the message below), make sure that all components of the Application Server have been installed.

These are installed in the Server Management area > Add Roles and Features.  The Application Server role is delivered with PowerShell commands that are required for IFS to run.

 

Update DSP for LBI

If you have installed a new DSP for your LBI server, it is very simple to point LBI to the new DSP install.

First, update the sysconfig.xml file located at <LBI Install Directory>/FrameworkServices/conf.  Look for the old DSP name and update it with the new name.  Then, be sure to change the class paths in WebSphere > Your Application Server > Java and Process Management > Process Definition > Java Virtual Machine.  Also, update the Custom Properties at the same location.

Restart the application server.

 

 

Installing DSP for Authentication Against LSF

You may find the need to install or update DSP for your SSO applications, such as LBI or MSCM.  DSP allows these external web application to authenticate against Lawson for Single Sign-On.

Information you will need:

  • The password for ssoconfig
  • The passkey used to install your current DSP version (if applicable)
  • FQDN’s for your LSF server and the server that hosts the application for which you are installing DSP
  • Credentials for an admin account (usually lawson)

 

First, download the latest DSP jar file from InforXtreme.

It is best practice to back up your ldap instance before you begin the install.

On the server of the SSO application, open a command prompt as administrator.  Navigate to the directory where you saved the DSP install file.

Type command java -jar <DSP file>.jar.  This will open the install wizard.


Enter a new configuration passkey.  NOTE that if you are updating an installed DSP, you will need to know what passkey was used to install it.

 

Give your DSP instance a meaningful name

 

Set the location where you want the install files saved, and set the java location.

 

Mingle DSP install is a different process not addressed in this article.

 

Provide the FQDN of your LSF server.  The standard and secure ports can be found in your LSF install log.  Enter the password that you use to run ssoconfig.

 

Enter account information with administrative privileges in Lawson

 

Enter the appropriate values for the server that hosts your SSO application

 

Click Install

 

Update the JVM custom properties with the new install information (if necessary)

 

Install or update your security application in WebSphere.  The install file lawsec.ear can be found in <DSP install directory/jar/secondary

 

Run a smoke test against the new DSP install at http://<application base url>:<port>/sso/SSOConfig

IFS Installer Fails with No Error Message

During a recent IFS install we encountered an install failure and the error message/return code was blank. The setup_log.log file said “Error: IFS -DoInstall failed with a return code of”.  We noticed that the setup_log.log claimed that it had created the new database successfully, but the database was not there. After much troubleshooting, we finally realized that we needed some inbound/outbound firewall rules for our IFS database instance. The interesting thing is that the install wizard made it past the database connection screen, but once we added those firewall rules, we were good to go.

Managing Groups in IFS

Active Directory groups can be added in IFS to use for synchronization and automated role assignment. To add a group to IFS, navigate to Manage > Groups. Click the add button to add a group, or click on a group in the list to update it. Selecting the “Sync users” checkbox means that users from that AD group will bey synchronized with IFS each time a sync is done. You can also auto-assign roles to users in the AD group by going to Manage > Master Data. Select Security Role, then Details. On the left side, select the role you want to assign. On the right side, click the Groups tab, and select the add button. Choose the group(s) for which that role should be assigned. Select Apply and/or Ok, then click the save button at the top. The next time you have a scheduled sync, all users in that AD group will be assigned the role(s) you defined.