DSP for Ming.le Fails on Installation

, ,

There is a common issue that may present itself when installing Distributed Security Package (DSP) for Ming.le.  The install will fail when trying to retrieve the trust store from the LSF server, with a message similar to the screenshot below.  There will also be exceptions in the LASE logs on the LSF server indicating a certificate issue (“Received fatal alert: certificate_unknown”).

Except from LASE log:

20-04-15 19:58:11:874 12 default.SEVERE authen.SSOServer.run(): SSOServer: Got unexpected exception when processing new secured connection com.lawson.security.server.LawsonNetException: Got exception while writing to connection /172.18.8.58,40001
Stack Trace : com.lawson.security.server.LawsonNetException: Got exception while writing to connection /172.18.8.58,40001
at com.lawson.security.server.AbstractDefaultEventSource.write(AbstractDefaultEventSource.java:299)
at com.lawson.security.server.Connection.<init>(Connection.java:170)
at com.lawson.lawsec.authen.SecuredConnection.<init>(SecuredConnection.java:39)
at com.lawson.lawsec.authen.SSOServer.run(SSOServer.java:180)Caused by:
javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2020)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1127)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:750)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at com.lawson.security.server.AbstractDefaultEventSource.writeMsg(AbstractDefaultEventSource.java:348)
at com.lawson.security.server.AbstractDefaultEventSource.write(AbstractDefaultEventSource.java:287)
… 3 more

 

If you come across this issue, you will need to add a line to the lsservice.properties file.

 

To handle multiple certificate in the keystore when LS as STS (Verify if your SSOP service definition has any of these listed for the PRIMARYTARGETLOOKUP; Use Ldap Binds, Verify passwords in Lawson Security, Use Claim Based, or Kerberos) or “AD FS” is configured, edit LAWDIR/system/lsservice.properties and add the property below.

 

server.keystore.use.classic=false

 

In a Federated environment the property needs to be added in federated systems that are configured to use STS or ADFS such as in the Landmark System configuration in the LAENV/system/lsservice.properties file there

 

Once this line has been added it will not take effect until you stop WebSphere and the LSF environment and then start the LSF environment and start WebSphere.

 

**NOTE**

If your LSF environment is federated with Landmark you should stop and start landmark after the LSF side of things are back up and running.

 

Revert LBI to a Previous Version

, ,

If you did an upgrade-in-place of LBI and are experiencing issues with it, you can revert to the previous version.

Before you begin a task like this, always get snapshots of your sever!!!

****If you don’t have a backup of your pre-upgrade database, then you won’t be able to complete these steps.  You can’t revert the database changes.  Always start with a database backup!!!****

 

Revert CRAS

You don’t need to perform this step unless your previous version of LBI requires a different version of CRAS.  To revert Crystal Report Application Server, you need to uninstall the new version, and reinstall the old version.  CRAS does not uninstall cleanly, so once you step through the wizard, and reboot the server, you will need to clear out the components left behind in the registry.  Here are the registry keys you may need to delete (key names may differ based on your version):

  • HKEY_LOCAL_MACHINE\SOFTWARE\SAP Business Objects\Suite XI 4.0\Crystal Reports\
  • HKEY_CURRENT_USER\Software\ SAP Business Objects\Suite XI 4.0\Crystal Reports
  • HKEY_USERS\S-#-#-##-…-####\Software\ SAP Business Objects\Suite XI 4.0\Crystal Reports

Reboot again.  Try reinstalling the older version.  If you get any errors during the reinstall, you may have left behind some keys in the registry.  You can search the registry for “Crystal”.

 

Uninstall LBI From WebSphere

In WebSphere Administration Console, navigate to Applications > Application Types > WebSphere enterprise applications.  Select all of your LBI applications (Framework Services, Reporting Services, Smart Notification), and Uninstall.

Reboot the server.

 

Rename the LBI Install Directory

Stop the IBM WebSphere Application server service, then rename your LBI install directory.  This way, you can install your previous version of LBI in the same directory.

 

Restore Data

Restore your pre-upgrade data to the RS, FS, and SN databases.

 

Reinstall LBI

Run the LBI install wizard for your previous version.  Verify that the applications were deployed to WebSphere and that they were started.  Perform smoke tests.

 

You should be ready to retry the upgrade!  LBI upgrades can be finicky with WebSphere and database updates.  I recommend rebooting between each component update.  So, reboot before you begin.  Then reboot after upgrading Framework Services.  Then reboot after upgrading Reporting Services.  And so on…

Database Errors after an LBI Upgrade

, ,

When using the wizard to perform an in-place update to LBI, occasionally the database scripts will fail without notification. The issue will typically present itself when you restart the IBM services and the SystemOut.log throws database errors, such as “invalid object name” or “field does not exist” after the application attempts to run a query.

The good news is that the database update scripts can be run manually.  These scripts can be found at <lbi_install_dir>\<product>\<product>.ear\<product>war-<version>.war\WEB-INF\rdbms\<database type>

So, for example:

  • D:\LBI\ReportingServices\Reporting Services.ear\erswar-10.6.0.0.war\WEB-INF\rdbms\MSSQL2K
  • D:\LBI\FrameworkServices\Framework Services.ear\efswar-10.6.0.0.war\WEB-INF\rdbms\MSSQL2K
  • D:\LBI\SmartNotifications\Smart Notifications.ear\lsnwar-10.6.0.0.war\WEB-INF\rdbms\MSSQL2K

You want to run all the update scripts that exist between your old version and your new version.  So, if you are upgrading from 10.4 to 10.6, you would run the highlighted scripts:

***IMPORTANT:  DO NOT run the oracle.sql or TreeSchma.sql script. They will drop all your tables.

 

 

 

10 Benefits of Hiring a Managed Service Partner

, ,

There is no doubt that the right managed service partner (MSP) can elevate your business and bring all sorts of new possibility within reach. Here are some ways that the right MSP relationship can benefit your organization.

  1. Economy of scale – Your managed service provider is likely servicing dozens of customers whose business is similar to yours. Therefore, instead of one subject matter expert (SME) to work with each client, a SME can handle the requests of three or four customers and reduce the overall costs.
  2. 24/7/365 coverage – Having constant, around-the-clock coverage of your entire application infrastructure is not realistic for every business. However, managed service companies specialize in this specific mode of operation and depending on the engagement will provide this coverage at no additional cost.
  3. Cross-client experience sharing – Your managed service provider likely has several customers who work with the same set of applications as your organization and therefore go through the same changes at roughly the same times. Very often when you report an issue to your managed service provider, they have been working with other clients on the same problem and can resolve it very quickly. This cross-client experience sharing is what gives MSPs the leverage to offer you lower costs than you would get on your own.
  4. Training – To maintain all your existing applications and to keep up with ongoing changes, you have to keep your staff trained and certified in multiple skill sets. It’s an unending task that is never near completion. Most IT managers will admit that their staff is far behind on their training plan. Your MSP however is trained and certified in all the right areas and maintains their certifications with all the software partners. You no longer have to worry about keeping up on a skill set that doesn’t have to do with your core business.
  5. Business focus – Your primary business is more than likely not managing applications. In an ideal world all your company staff would be focused on the core of your business and not on operating payroll, financial, and inventory control applications. That is exactly the kind of focus you will gain by partnering with the right MSP.
  6. Proactive maintenance – Most IT departments are focused on keeping the lights on and break-fix issues. Proactive maintenance has become a luxury most companies can’t afford and rarely even think about. Your managed service partner profits only when the number of hours it takes to maintain your account is less than the monthly fee you have committed to. With interests aligned in this way, your MSP will take a more active role in making sure things are maintained well and they break far less often.
  7. Skills coverage – Many of the skills required throughout the year to maintain all your applications are one-off skills that never really become relevant again. It doesn’t make a lot of sense to train your staff in installation, upgrade, and setup of your applications when those tasks are only happening once every few years and changing each time. Your MSP partner, however, uses those skills with several clients and will always have trained staff on hand for such tasks.
  8. Single point of ownership – Having single point of ownership for trouble tickets, maintenance, change control, SLAs, and application related upkeep ensures that work gets done without the need to coordinate between several parties and the buck doesn’t get passed around.
  9. Reduced downtime – Proactive maintenance, the presence of a skilled and ever-ready work force, and around-the-clock coverage means the potential for downtime would be reduced to nearly zero.
  10. Leaner staff – With all the distracting applications managed by your MSP, you are now free to focus on the core applications that run your business and give you competitive advantage in the marketplace. Your team can be leaner and more focused without the need for staff with narrow skills for single-use applications. Most organizations are able to reduce their teams by 30% when partnering with a MSP.

 

Learn more about our managed services page here

How to choose a Managed Service Partner

, ,

In today’s fast changing IT landscape, you need a managed service provider (MSP) that understands your needs and whose business model is aligned with your organization. Keep in mind the following areas when choosing a managed service provider for your business.

  • Specific application expertise: There are thousands of managed service providers within the US. Many of them claim to work with dozens of applications. It is important however that your main applications are properly supported, and the expertise of your MSP team exceeds and enhances that of your own internal team. For that reason, we focus mainly on Infor, Lawson and Kronos applications and some of the ancillary applications that are usually installed with them (MHC, BSI, API, ImageNow, Ascend …). Make sure that your MSP partner is in good standing with your software vendor and is certified to deliver services related to those applications.
  • Industry specific knowledge: Every industry has its own special challenges and choosing a managed service partner who has worked with clients in your industry can make a big difference in your level of success. An experienced MSP can also bring best practices from others in your vertical to help you be more efficient.
  • Client references: The best indicator of the quality of an MSP is what their clients have to say about them. Check reviews and ask to speak to their customers before you select an MSP.
  • State-side availability: Many of our clients find it imperative that our staff is not outsourced to foreign countries and all the work is performed state-side. If this is important to your organization, ensure that your MSP partner has a presence where you do your business and will not be impacted by geo-political issues that might otherwise interrupt their services.
  • Methods of engagement: You need to find out ahead of time how your users can engage with your MSP. Some MSPs employ a cumbersome ticketing process that can add hours if not days to the resolution of each issue. We have long adopted a policy of working within whatever ticketing system our clients are already working with so as to remove any friction from resolving issues. We also encourage customers to call or emails us directly if they feel like that will facilitate faster resolution. Be sure to understand the way your MSP works before committing to long term relationships.
  • Avoid long term commitments: Committing to a service provider is a big business decision that can impact your organization significantly. It is always advised to insist on a short-term commitment whenever possible. We don’t lock our clients into long term contracts for this very reason. In reality, if a customer wants to change service providers, it doesn’t make sense to force them to stay, but many MSPs still insist on multi-year contracts in order to break even with long and expensive sales cycles and hefty commissions.

 

Learn more about our managed services page here

Troubleshooting External Web Server Issues

, ,

Configuring Lawson on an external web server is pretty straightforward…until you have issues.  The most common symptom I have run across is a 404 error when you open the web page, which typically indicates that external web server can’t find sso/sso.js.  (A quick Fiddler session will confirm that for you).  That is the first time the external web server is reaching out to the Lawson application server, so that error message indicates that you have a communication failure between the two web servers.  There can be many reasons for that communication failure, from bad plug-in files to bad certificates.  Here are just a few things to review:

  1. Make sure your modules are mapped

Navigate to WebSphere > Applications > Application Types > Websphere enterprise applications.  Select the IOS application and click “Manage Modules”.  Make sure all modules are mapped to all servers (web and application).  Do this for IOS and LawsonSecurity.  You can also check RQC and BPM for good measure.

  1. Check Virtual Hosts

Navigate to WebSphere > Applications > Application Types > Websphere enterprise applications.  Select IOS.  Under “Web Module Properties” on the right, click “Virtual Hosts”.  Make note of which virtual host IOS is using.  Then, under Environment > Virtual Hosts, click the host being used by IOS.  Make sure that your External Web Server port is in the host alias list.  NOTE: if your external web server is using the same port as your internal web server, it is best to give explicit aliases for that port.  Add an alias with the fully qualified domain for each server, and the port being used.

  1. Check your plugin-cfg.xml

Make sure the plugin-cfg.xml on your external web server looks right.  On your external web server, you should find the plugin-cfg file at <IBM Plugins Directory>/config/<Web Server Name>

It should have some basic properties.  First of all, it should contain all the virtual hosts that you just checked in step 2.  Secondly, it should contain some Uri’s specific to Lawson (not just the default WebSphere application).  Here is an example of a “bad” plugin-cfg file compared to a “good” one.

BAD – does not have all my virtual hosts

BAD – does not have any lawson-specific Uri’s

GOOD – all my virtual hosts are represented, including the host aliases I set up for duplicate ports

GOOD – there are my lawson-specific Uri’s, including that sso directory that was giving me trouble at the very beginning

The best way to resolve issues with your plug-in file is to regenerate it from your Application Server WebSphere console.  Go to WebSphere > Server Types > Web Servers.  Select your external web server and click “Generate Plug-in”.  You can’t propagate it, because it is on an external server, and it belongs to an unmanaged node.  So, make note of where the config files was saved (at the top in the Messages section).  Navigate to that location on your server and grab the file.  Copy the plugin-config.xml file and the plugin-key.kdb from that location to the plugins location noted above on your external web server.  Restart your World Wide Web Publishing service on the external web server, and test your external URL.

  1. Check the WebSphere certs

If you are having certificate issues in WebSphere, you might be seeing the 404 error in a Fiddler session, but you might also be seeing a 500 error.  Your first stop is the http_plugin.log on the external web server.  If there are certificate errors, they will be noted here.  Look for “GSK” errors.  This could mean your WebSphere certificate has expired, or there isn’t a trust between the application certificate and the external web certificate.

In WebSphere, navigate to Security > SSL certificate and key management > Key stores and certificates > CellDefaultKeyStore > Personal Certificates.  Make note of the serial number on that certificate.  Then go to the CMSKeyStore for your external web server.  Again, make note of the serial number.  If they are not matching, you’ll need to replace your external key store cert with the internal one.

To do that, first import the CellDefaultKeyStore into the web server CMSKeyStore.  In the CMSKeyStore > Personal Certificates for your external web server, click the “import” button.

In the dropdown, select the CellDefaultKeyStore, and click “Get key store aliases”.  This should populate the “certificate alias to import” down below.  Select the correct certificate to import (most likely “default”).

Give the certificate a new alias.  Click “Apply” and save changes.

Now, you need to replace the old certificate with the new one.  Under certificates, select the “old” cert and click “replace”.  Select your new cert in the “replace with” box.  You can choose to delete the old cert at this time, but it’s actually safer to delete it manually after you smoke test.  Restart the application server, or better yet, reboot!

5 Best practices in working with Managed Service Providers

, ,

We have been working with dozens of clients over the years as their managed service partner (MSP), managing Infor applications. In 2020, we decided to make a list of some practices that have made our relationship with our clients more successful. You can employ these same practices with your MSP to achieve the same level of success.

  • Single point of ownership – Each member of our staff works with several customers on a daily basis. We often communicate with several managers, IT contacts, and dozens of users within dozens of clients. While this communication is highly efficient and facilitates progress well, it is imperative that communication regarding important decisions are handled by one key person on each side. The most successful model we have found is if one of our managers reports directly with a manager at the client’s end and all decisions regarding projects, progress, personnel, and money are made between those two designated people. Otherwise things my get approved by someone who doesn’t have the proper authority to approve the work, which is never a good thing.
  • Change control inclusion – Including the MSP in your change control discussions is extremely valuable. Your MSP is in charge of several applications and is often the only party within the organization that is aware of the impact of changes to certain applications. It is also important that your MSP understand your change control processes so as to not accidentally circumvent them.
  • Proper planning – Clients who meet with us on a quarterly basis to do forward budget planning and general forecasting have shown a higher level of satisfaction and derived more efficiency from our services. This usually takes the form of a one hour meeting each quarter to look back on the past quarter and look forward to the next three quarters with major milestones and projects in mind.
  • Clear the path – We work with many hospitals, banks, government organizations, insurance companies, schools and retail chains. Our clients have all agreed to a remote method through which we can manage their systems. However, these systems vary quite a bit and some cause more waste than others. Work with your MSP to determine if there is a method which suits their workflow better and that you can also accommodate.
  • Full transparency – Trust in a relationship is built over many years and can be destroyed within a short moment. That is why full transparency is vital to a relationship with your MSP. This spans all facets of your relationship. From proposals, to time sheets and invoices, we go out of our way to disclose every available bit of information to customer so they can have full visibility into our progress, work efficiency, and their overall financial commitment.

 

Learn more about our managed services page here

Setting Up IFS Bootstrap For LDAPS

, ,

Our article “Configuring Lawson for LDAP Signing” takes you step-by-step through configuring your environment for the new LDAPS requirements being enforced by Microsoft later this year.  That article discusses how to configure IFS for LDAPS, but after we got a few questions about the procedure, we decided to clarify it further.

When IFS is installed, a “Bootstrap” parameter is created to link to the root of your active directory.  This parameter is only utilized to bring users from AD into Lawson.  It should look something like this:

To configure IFS for LDAPS, you will need to update your Bootstrap to use the host name of one of your domain controllers, and you will also need to provide the credentials of a user that has authorization to search the AD tree.  This bootstrap connection is not actually used for authentication, so it shouldn’t be a problem that you have multiple DCs.  It is only used to bring users into IFS from Active Directory.  As long as the user connecting to that DC has the ability to search the tree for users, you should be fine.

Your URL is going to look something like LDAP://server.company.com:636/DC=company,DC=com.  Essentially, you just need to add the server name and port to the bootstrap value.  Remember that the protocol is “LDAP” not “LDAPS”.  To change the IFS parameters, just click into the boxes, and start typing.  Click the “Save” button at the top when you are done.

To make sure your settings are working properly, click the “Test” button, and you should receive this message:

Why You Shouldn’t Use Port 636 to Bind to LDAP Signing

, ,

The normal LDAP Signing ports are 636 and 3269.  Port 636 is the default signing port, and 3269 is called the Global Catalog Port.  Here is why you should only use port 3269 (if possible) when updating your LDAP Bind for LDAPS.

The default port (636) is used for searching the local domain controller, and it can search and return all attributes for the requested item.  The Global Catalog Port also searches the local domain controller, but only returns attributes marked for replication to the Global Catalog.  If you don’t need all attributes to be searched and returned (and for Lawson binding, you don’t), then using Global Catalog can be much faster.

If you choose to use the default port, be aware that there might be some performance issues, and maybe even timeouts, when users are logging in.  This can impact you, even if you are authenticating AD FS, because some pieces of the application still authenticate using LDAP Bind.  For instance, IPA nodes that have to authenticate against the Lawson server (such as file access, Lawson Query, etc.)

If users are experiencing latency or timeouts when logging in, you may see a “connection reset” error in your LAWDIR/system/security_authen.log file, similar to the error below:

Another symptom of a slow default port search is IPA processes throwing a login error when trying to make a connection to Lawson.  You might see an error similar to this one in your Work Unit logs.  This exception was thrown on an RM Query Node:

The best course of action if you are experiencing these issues is to update your LDAP Bind to use port 3269 instead of 636.  Check out our article on Configuring Lawson for LDAP Signing for step-by-step instructions on how to update the LDAP Bind.

LDAPS Certificates

, ,

We’ve been getting a lot of questions about the certificates needed for LDAPS.  This article will provide some general information about working with certificates, and the specific requirements for LDAPS.

To create a certificate, you need to retrieve it from a certificate authority (CA).  An example of a CA is a site such GoDaddy, but there are many, and your networking team probably already has a CA that they use.

The certificate needs to have a Subject Alternative Name, and it needs to be exported as PKCS12 with a private key.  When you or your networking team retrieves the certificate, they will apply a password to the private key.  They will need to provide you with the “.pfx” certificate file with the private key exported, and you will need that private key password.  You will need the file and the password so that you can import the certificate to the AD LDS service account.

The requirements for your LDAPS certificates are actually pretty standard.  It is important to note that the certificate must be created with a Subject Alternative Name.  That is becoming more standard, but we’ve seen plenty of certificates that don’t have a SAN, so just make sure yours does.

You can view the properties of your certificate in the Microsoft Management Console.  You can do this on the server, or from another computer as long as you have network access to the server where the computer resides.

To view certificates in MMC, click start and search for “mmc”.  Select “mmc.exe”.  This will open the Microsoft Management Console.  From there, click File > Add or Remove Snap-In.  Choose “Certificates”.  Select “Computer Account”.  If you are on the server where you want to view the certificate, select “Local Computer”.  Otherwise, select “Another computer” and enter the server name:

Click Finish and then Ok.  The certificates for that server will populate in MMC.  Typically, you will be looking in the personal store.  Simply double-click on the certificate that you want to review, go to details, and look at the properties for the certificate.  You can see all the properties, including the Subject Alternative Name.