LID performance issues on LSF9

I woud like to hear what other think of this problem or work around for this issue.


Sopheap

I thought that there would be some tuning parameters, but so far Lawson GSC has not been able to offer any. I'm wondering if this is some kind of network or hardware issue, but it is very difficult to narrow down.

I noticed that you wrote Windows Server 2003 SP2...is it basic straight server or Enterprise/Data Center Ed?

Since we have installed 900.4 into our training environment, we have noticed a slow down with Portal. My co-worker tracked down an helper that said if you use processflow, this could be possible. The helper had my co-worker add an entry to a table (I believe in LOGAN) and it has helped.
Are you using ProcessFlow?

How is your local Lawson group defined? Does it include AD (or perhaps nested AD) groups, or are all users defined as local users on that server, etc.?   How "far" is the Lawson server from the AD controller(s)?  One issue I've come across recently is that Windows 2003 SP2 does something with Kerberos which causes lengthy discussions with the AD controllers when looking up job related records that require AD authentication, and tries to drop down into NTLM authentication instead of AD/Kerberos.  For some reason the same issue doesn't occur in Portal (I'm assuming Portal does a better job of caching it than LID).  Look in the event logs on your Lawson server and see if you have any errors ... The "solution" was to define an 'SPN' in order to force Kerberos over NTLM.  As always, I'm a little out of my element on this, but hopefully someone who understands this more than I do will chime in...

We running 2003 R2 Enterprise edition. Our AD instance while not on a dedicated server is only 3 feet away and all the LID users are local in the building. I'm not an AD expert but I think it's a pretty plain vanilla setup. We do have ESS, Processflow Professional and Smart Notification running on our Lawson system as well but there is minimal usage. Lawson GCS is leaning towards AD as the culprit and want us to turn off security to see if the LID performance improves. Apparently LID does go out to AD repeatedly to read security when jumping around in LID.

If you are using ProcessFlow even a little bit, we have found that if we add a record in ProcessFlow Administrator that performance has increased.
Go to ProcessFlow Administrator: Click on Interface Definition, pull down the System Name drop-down box, and select "WFCONFIG - WfConfig"
Field Name= CAT_SEARCH_ORDER Inquire.
In the Field Value box, make sure that you have a "N" without the quotes.

Hope this helps. --- We only noticed it after applying SP4, which it indicates you are running.

That would be very wierd...to have a ProcessFlow issue affecting LID performance...but I've been wrong before...
I'd pursue the AD Kerberos vs. NTLM issue...as that seems to be the issue at another client; please post whatever you figure out...

I should say, John- We are 100% Portal shop here since upgrading to LSF9, so we really don't have enough people using LID to be able to evaluate the performance of it. Just us here in IT. It DID make a noticeable difference in our Portal performance though, so I thought I'd throw it in the ring just in case it would apply to LID as well.
Thanks for keeping me honest.

Oh, I wasn't questioning your honesty, just my sanity...

I've not used Pflow V 9 much since we migrated, but I don't see Interface Definition as an option in my Processflow Administrator screen. One thing I did find in the Lawson sever's Windows security event log is an "advapi" authentication error for one of the users having performace issues. Would this indicate thay dropped down from Kerberos? According to the user they were not actually logging in and out, so I'm assuming these were authentication attempts being made on behalf of them by lawson for their job processing. Eventually the error changed to account is locked out, but when I had my network admin check a while later it was no longer locked. We have an auto unlock set up so I'm not sure if the account automatically reset or if the locked msg was bogus.

<!-- Converted from text/plain format -->

The advapi probably indicates a permission issue on the registry keys used by Lawson to store the user's password, etc.

That's interesting, I wonder why it would be intermittent? It's also interesting that despite the errors, they were able to run their jobs successfully.
Is this referring to the registry on the users machine or the registry on the lawson server? I thought only the lawson service account read and updated the registry on the server.

Hi,

I'm curious if you've been able to find a fix for your performance issues?  We are a very similar configuration (Windows 2003 server, running LSF 9, apps 9, Oracle, IIS, Websphere 6.1).  We DO NOT have Process Flow and are seeing the same type of random "hanging" on forms in both LID and Portal.