image

If you haven’t already done so, implementing SSL after the install is a bit of a black art. Without going into gory detail, here’s a very simple set of steps to follow:

  1. On the LSF server turn off all the services related to lawson aside from ADLDS
  2. Import your new certificate (preferably a wildcard cert) into windows as a personal cert
  3. Create a binding within IIS using the imported certificate on port 443
  4. Load up  your favorite ldap editing tool. We prefer this one.
  5. Under O=lwsnrmdata -> OU=resources you’ll find all your users and services. You’ll want to edit the following identities (or more if you have other service URLs):
    • BPM
    • IOS
    • IOSAdmin
    • LSAdmin
    • mingle
    • mingle_env
    • SSO
    • SSOP
    • Environment
  6. In each of the cases above you’re going to modify the Service URL and any other http protocol. You’ll also want to change the PROTOASSERT attribute from “Use HTTP only” to “Use HTTPS always”.
  7. Then change every relevant entry in %LAWDIR%/system/install.cfg that refers to http, protoassert, or the secure ports. They’re relatively easy to find.
  8. You can now reboot the LSF server and restart your services.
  9. If you have Landmark installed, then bring up the rich client
  10. In the GEN productline, navigate to: “Security System management” > Services
  11. Change every service to HTTPS_ONLY and change the service properties to HTTP Port=-1 and HTTPS Port=443
  12. Change all the relevant entries in system/install.cfg
  13. Reboot the Landmark server
  14. Run all the smoke tests with updated URL to verify everything is working
  15. If you are using inbaskets you’ll want to import your certificates into Websphere as well but that’s a topic for another article

When you upgrade to Lawson version 10, you might notice some issues with session timeouts. The most common issue that I’ve seen is that the user will get 30+ blank popups. IF they have the patience to close each popup individually, they can eventually get back to the browser screen and close it. That’s the only way to start a new session. However, most users do NOT have the patience to click 30+ times, and they end up having to kill their browser session in Task Manager. Either way, it is no fun.

Here are some examples of the popups:

How to Resolve Infor Lawson 10 Session Timeout Errors_1

How to Resolve Infor Lawson 10 Session Timeout Errors_2

Luckily, with several encounters of this bothersome task, here is a solution on how to fix it:

Step 1: Make sure you are on the highest patch level of ios.jar and lawsec.jar for your version of Lawson.

  • You can find your current version in LID by typing in the commands “univver ios.jar” and “univver lawsec.jar”.
  • Then, you can check with Infor support to determine if you need to update, and they will direct you to the appropriate patches

Step 2: Copy the msgdlg.xml to the appropriate location

  • The system seems to generate all these popups in a panic because it can’t find the msgdlg.xml file where it is expected
  • Navigate to LAWDIR/persistdata/lawson/portal/data/msgs/en-us.
    • If the msgdlg.xml file is there, COPY it to WEBDIR/lawson/portal/data/msgs/en-us
    • If the msgdlg.xml file is not there, ask Infor to provide it for you
  • Once you copy the file over, upon session timeout you should receive ONE popup message. Once you click OK, you will be taken back to the logon screen where you can start a new session.

How to Resolve Infor Lawson 10 Session Timeout Errors_3

If you have every had to figure out what version of a certain Java executable you have you will appreciate this simple trick. Simply point your browser to this url:

Example:

This example displays the version of the ios.jar file as shown below.

How to determine the version of your Lawson jar files

In the above case the version of ios.jar file on the server is 9.0.1.11.521.
This information can be very helpful when working with Infor support to determine if patches are needed.

During an upgrade, re-pointing all your LBI reports to your new database may seem like a daunting task. Never fear! You don’t have to do it manually (at least not all of them). Here are the steps to overwrite your data sources using a SQL update query:

  1. Create an ODBC connection on your LBI server that connects to your NEW database server.
    1. Don’t forget that you have to use the 32-bit ODBC tool for LBI data sources!
  2. Create your new data source in LBI
    1. Tools > Reporting Services Report Administration > Server Administration > New Data Source A More Efficient way to Update Report Data Sources_2
  3. Open SQL Server Management Studio (or whatever database management tool you use)
  4. Log-in to your LBI database server
  5. Navigate to the LawsonRS databaseA More Efficient way to Update Report Data Sources_3
  6. BACK UP YOUR ERS_REPORTDATASOURCES TABLE! (You should always back up the table or the database if you are making changes directly)
  7. Run a query to view all the reports for which you plan to change the data source: A More Efficient way to Update Report Data Sources_4
  8. When you are ready, run your update query using the same WHERE clause that you used when you viewed your reports in step 7
    A More Efficient way to Update Report Data Sources_5

    1. NOTE: you are updating RSDATASOURCE. This is so that the report data source will be overridden.
    2. If you have a new username & password for this data source, you will also need to update the DEFAULTUSER and DEFAULTPASSWORD fields as well.
  9. Now your reports should run against the new data source. There are a few cases in which you will need to manually reset the data source in Crystal and republish the report. They are:
    1. If your report mixes schemas (i.e. it uses tables owned by dbo, and views owned by xyz)
    2. If your report has subreports
    3. If your report has a command that explicitly defines the database name (and the database name has changed)
    4. There may be more, but these are the instances that I discovered on a recent upgrade!

So your client has scheduled LBI reports that they rely on and for whatever reason, it didn’t run on the day it was scheduled for. Now, it’s Monday and it’s too late to run the report manually! Furthermore, the client wants the report to be available in the LBI “History” section of the report viewer for later reference.

We click this past scheduled report…

How to Fix a Scheduled LBI Report That Didn’t Run Properly_1

Oh No! Our Revenue Check Daily – MRN didn’t run properly!

How to Fix a Scheduled LBI Report That Didn’t Run Properly_2

First thing we need to do is start Crystal Report and open the latest instance of our editable report. For our client, this is located on their LBI server in: D:\LawsonDocuments\60_Revenue Check Daily – MRN\

How to Fix a Scheduled LBI Report That Didn’t Run Properly_3

Once your report is open, either enter the date parameters for the report (if it takes parameters) or hard code the dates in the report to reflect the day it was supposed to grab data from. Don’t forget to set the front-end display dates that the end-user will see.

Once the data is verified by the end-user, export the report in crystal format.

How to Fix a Scheduled LBI Report That Didn’t Run Properly_4

How to Fix a Scheduled LBI Report That Didn’t Run Properly_5

Select a directory and name you want your crystal report to export.

Now, find the directory of the instance that didn’t run properly or simply does not exist.

For me, this was D:\LawsonDocuments\60_Revenue Check Daily – MRN\Instances\2016-04-08_1606\

How to Fix a Scheduled LBI Report That Didn’t Run Properly_6

If a crystal report exists in that directory, delete or move it elsewhere.

Now copy in your exported LBI report that you edited and rename it to the exact name of the report + “_instance number”.

Ours is Revenue Check Daily – MRN + _1606 so Revenue Check Daily – MRN_1606

How to Fix a Scheduled LBI Report That Didn’t Run Properly_7

The instance number can be found in the folder name that is generated by LBI.

That’s it! You can now go back to LBI Report Viewer and click on that report that errored out earlier.

How to Fix a Scheduled LBI Report That Didn’t Run Properly_8

Administering Lawson on Windows has traditionally required using the basic toolset within windows to get things done. With Windows 2012 it seems like some of the very basic tools users are used to are hidden away and require several extra clicks to get to. Here are some quick ways to make Windows 2012 easier to deal with:
Method 1
Install a 3rd party tool called Classic Shell found here: https://www.classicshell.net
This is by far the easiest way to get Windows 2012 to act more like Windows 2008.
How-to-Setup-Your-2012-Server-for-Easy-Administration_1
Method 2
Since installing 3rd party applications like Classic Shell is not going to appeal to every client. Here’s a quick way to get at least your programs menu back without the help of any 3rd party applications:
Steps (4 total)
  1. Display “Hidden items” on your C: Drive – Open File Explorer and browse to your C: Drive. On the View tab, check the “Hidden items” checkbox.
  2. Add a New Toolbar on your Taskbar. – Right-click on a blank area of your Taskbar and select Toolbars > New Toolbars.
  3. Browse to the Start Menu\Programs folder. – In the New Toolbar dialog box, browse to the “C:\Program Data\Microsoft\Windows\Start Menu\Programs” folder.
  4. Click the “Select Folder” button. – Click the “Select Folder” button to add the new Toolbar to your Taskbar.

After dust from the upgrade settles, it’s usually time to automate any and everything that can be automated. When it comes to Lawson (LSF) related services though things can get a big tricky.

There’s a precise order bringing up the services on windows and one way to ensure this happens correctly is to setup service dependencies on your windows applications server.

Let’s first review what depends on what and why.

The services that need to come up are in order:

  1. ADLDS
  2. Lawson Environment
  3. IBM Webshphere Cell Manager (Optional)
  4. IBM Websphere Node Agent
  5. IBM Websphere Application Server
  6. Web server (IIS)

Obviously, since all the authentication work happens through ADLDS, it makes sense that it would be the services to come up first. And since ADLDS has it’s own set of dependencies, we don’t need to create new ones there.

Next we setup a dependencies for the Lawson Environment Service to depend on ADLDS.

To do this, bring up the services window (Start-> Run-> services.msc).

Right click on your ADLDS service and note the service name.

Right Click on your Lawson Environment Service and note the service name.

Now bring up a cmd prompt as administrator and type in the following command:

sc config [service name] depend= <Dependencies(separated by / (forward slash))>

Note: There is a space after the equals sign, and there is not one before it.

Warning: depend= parameter will overwrite existing dependencies list, not append. So for example, if ServiceA already depends on ServiceB and ServiceC, if you run depend= ServiceD, ServiceA will now depend only on ServiceD.

Example:

sc config laserv-prod depend= ADAM_ProdInfor10ADLDS

In the above example, my Lawson environment service is called “laserv-prod” and my ADLDS service is called: “ADAM_ProdInfor10ADLDS”.

Once you hit enter, a message should appear that says: “[SC] ChangeServiceConfig SUCCESS”

You have now setup a dependency for the Lawson Environment service to depend on ADLDS. You can confirm this by checking the service properties:

How to setup dependencies for Lawson services_1

Now you can continue with the rest of the services and setup dependencies as you go. Keep in mind that the Cell manager is really an optional service and you may not want it running all the time, so you can avoid that dependency if you like.

Next, you’ll want to change all the services named above to be automatic. We usually don’t setup any recovery options as they can lead to some unintended results.

In the end, your Web Server’s dependencies should look similar to this:

How to setup dependencies for Lawson services_2