Author Archives: Rickard Eklind

Scaling out Smart Office server

Scaling out the Smart Office server can be done for different reasons. Being able to serve more users or creating a more robust environment.

When talking scaling out an environment it is not only Smart Office server that needs to be considered, it is also the Grid Registry, Grid Session Provider and the connection points into Grid (Grid Routers) that must be included.

This article will describe one way of creating an environment with Smart Office that can handle a larger amount of users and also be more resilient for malfunction hardware using Infor Smart Office 10.2.1 and Infor ION Grid 11.1.13.

As a starting point Grid, LDAP Session Provider and Smart Office have already been installed.

Adding a host to Grid

The first thing needed is to add another host in the Grid and to be able to do that the host must first be added in Lifecycle Manager (LCM). The process of adding a host in LCM is described in the LCM install guide. The steps are shortly described below.

  1. On the new host go to the LCM portal page, normally http://server:4062 and download the Service Installation.
  2. Install the service with java.exe –jar installLcmService.jar
  3. After the installation the new host will be visible in the LCM client.

Now when LCM knows about the new host, Grid needs to span to the new host as well.

To add a host to the Grid:

  1. Find your Grid in the LCM client, right click on Grid Hosts and select Add Host.
  2. In the Add Host dialog, select the host previously added to LCM and press Next followed by Finish. Change ports, name etc if needed.
  3. In the Grid Topology View the new host should be visible.

Grid Registry

The Grid Registry cannot run simultaneously on several hosts, it can only run on one host at a time. But there is a failover mechanism. The failover mechanism will make sure the Grid Registry starts on another host if the primary host malfunctions.

To enable failover for Grid Registry do the following.

  1. In the LCM client find the Grid Hosts, right click on the ones that is tagged with registry and select Configure Registry Failover.
  2. In the Configure Registry Failover dialog, select the new host and press Next followed by Finished. (The Grid needs to re-start when changing the Grid Registry failover settings).
  3. Wait for the configuration task to finish and Grid to start again. On the failover host should now be tagged with failover.

Grid Routers and Load balancer

A load balancer must always be placed in front of Grid to be the single entry into the Grid to ensure that even if a host where a Router exists on dies it is still possible to connect to the Grid. A client will not know if a Grid host is failing or another host is added since it always connects to the load-balancer. But what if the load-balancer dies? There are techniques for having clustered load-balancers as well, but that is out of scope for this article.

In order for the load balancer to balance the calls to different servers there must be a Grid Router on each host. The load-balancer is configured with the hosts and https ports to the Grid Router on each host.

The load-balancer should also have a health mechanism so it automatically removes a hosts if it malfunctions.

Where to put the SSL certificate? In the load balancer, in the Grid Routers or in both can be debated. There are pros and cons with all solutions. The solution that works best with all Grid Session Providers and has less security flaws is to put the SSL certificate in the Grid Routers and configure the load-balancer for TCP pass-through.


Note that the SSL certificate used in each Grid Router must be issued with the load balancer address and it is recommended to use the same certificate in all routers.

Grid Routers

Either create a new Grid Router on each host that should be included by the load balancer or configure one router to be on started on <all hosts>.


Below is the Default Router set to be started on all hosts and they will all be using the same HTTPS port.


SSL Certificate

SSL certificates are managed per host, not per Grid Router, and must therefore be added for each host. It is recommended to use the exact same certificate on all hosts, clients may be confused if getting a different SSL certificate depending on which host is being called through the load balancer.

Before creating any SSL certificates decide the address of the load balancer.

To create a SSL certificate from an internal Certificate Authority (CA) and add it to all hosts do the following.

  1. In Grid Management Pages go to Configuration Manager -> Security->Certificates and click Manage Certificate on one of the hosts.
  2. Click the Create Certificate Signing Request (CSR).
  3. In the Create Certificate Signing Request (CSR) dialog make sure to change the Host FQDN (CN) value to the load balancer address. In this example I have also added the two host names as alternative names to remove certificate error if accessing them directly without going through the load balancer. It is not necessary to do so. Click the Create Request Overwrite Keys.
  4. Send the certificate request to your Certificate Authority and receive a certificate chain back, usually a .p7b file.
  5. Now import the certificate chain by clicking Import Signed SSL Certificate and select the file received from the certificate authority, followed by  Import Certificate, followed by Import.
  6. The SSL certificate is now located on one of the hosts, to be able to import it on the second host export the SSL certificate by clicking Export SSL Certificate with private key. Use Oracles Java key-store and give the key-store a password.
  7. Go back to Configuration Manager->Security->Certificates and select the other host.
  8. Click Import SSL Certificate with private key. Select the file previously exported.
  9. Now both of the Grid Routers will use the same SSL certificate.

Load balancer

In a production environment a load-balancer is most often a piece of hardware, for more information contact your hardware vendor. In a test environment a software load-balancer can be used. For this blog post I used which has a community edition that is free and works on several operating systems including Windows. In my example I have configured nginx with TCP pass-through to two servers. The configuration file is similar to this.

stream {
  server {
    listen 3443;
    proxy_pass grids;
  upstream grids {

For more details see the nginx documentation.

Grid Applications

Some Grid Applications can be scaled out to several machines, other cannot. Some can run several instances at the same time and some cannot. Both Smart Office and the different Grid Session Providers are Grid Applications and have some different characteristics. The details are listed below.

Even if a Grid Application cannot run two instances at the same time most Grid Applications can be started on another host if the original host dies. Within minutes a fully working environment is up and running without human interaction.

There are a couple of things that needs to be prepared and considered when implementing a complex environment when it comes to Grid Applications.

  • Deploy Grid Applications to hosts
  • Configure Grid Bindings
  • Make sure there is enough memory

Deploy Grid Applications

Deploying a Grid Application to a host is a matter of distributing the binaries, nothing will run just by deploying a Grid Application to one or more hosts.

To deploy a Grid Application to a host, in the LCM client find the installed Grid Application, right click and select Application Maintenance->Deploy Application on Hosts


In the Deploy Application on Hosts dialog, select the hosts where the application should be able to run and press Next. Press Finish.

The Grid Application is now possible to start on all hosts it is deployed to.

Grid Bindings

The Bindings for a Grid application is found on the application page in Grid Configuration Manager.


Click the pencil to edit the Binding.


For a robust scenario you would like to have the Grid Application run on a minimum of two hosts always to ensure having at least one instance running even if a host dies. Mark the hosts where this binding should be enforced and select Constraint Type to be Per Host. This configuration will result in one instance of the application running on each of the selected hosts.

If having Constraint Type set to Global and Min to 2 would result in almost the same behavior. There will still be two instances of the application but it is not defined if the running instances will be started on the same host or not.

When having an application that only can run in a single instance the following configuration would result as a failover behavior. Constraint Type = Global and Min = 1.


If the host where the application run on dies, Grid will make sure that the application is started on another host that has been marked in the Binding. By using the Preferred Host property it is possible to hint where the application should run if all hosts are working fine. Within minutes a new instance has started if the first host dies.


When having Grid Applications that cannot run several instances at the same time but have deployed the application to several hosts Grid will start the application on another host if the preferred host dies. Verify that there is enough memory left on the host where the application is supposed to start before a failover will occur.

Note that memory consumptions from other application will not be taken into account.

Grid Session Provider

There are several Session Providers that can be used in Grid (LDAP, Windows, SAML and DSSO). In practice it is only the SAML Session Provider that supports both failover and can run on multiple hosts and there fore . For these reasons it is recommended to always use SAML Session Provider in environments that requires high stability.

Use the methods describes above to deploy the session provider to additional hosts and configure the bindings. The table below describes what each Session Provider supports.

Session Provider Can be deployed to several hosts Can run multiple instances
LDAP SP 1.10.14 Yes* Yes*
Windows SP 1.10.7 Yes No
SAML SP 1.13.12 Yes Yes
DSSO SP 2.0.7 No No

* LDAP SP can only be deployed to several hosts if configuring the connection to the LDAP with the LDAP protocol. If using LDAPS or Start TLS protocol the LDAP SP will not function properly if deployed to another host. Note! The LDAP protocol should never be used since it sends userid and password in clear text over the network.

Configure Smart Office when using a load-balancer

The Smart Office server must be configured to execute on more than one host and the installation point must be configured to use the load-balancer.


Configuring Smart Office server when using a load-balancer is done with a few steps.

  1. Deploy Smart Office Server to more than one host by following the steps above.
  2. Configure the Smart Office binding to use more than one host, set Constraint Type to Per Host and set Min to 1. After saving the Binding the Smart Office will immediately start on the new host.

Installation Point

When installing the Smart Office client Microsoft Click Once verifies that the installation point URL stated in the installation matches how the installation is accessed. When accessing the installation point through a load balancer, it is the load balancer address that must be put in the Click Once installation. The Smart Office client must also know the URL to the Smart Office server, which also goes through the load balancer.

To change these URLs open the management pages for Smart Office in Grid Management Pages and click Installation Point Configuration.


Change the Installation URL and HTTPS URL to the Grid to point to the load balancer. I am using the https port only but if the load-balancer is configured to pass through both http and https, http can of course still be used for the installation point. Do not forget to save (some versions of Smart Office has a bug that wrongly shows the old values after saving).


Now use the normal procedure described in the installation guide on how to export/sign/import the installation point.

To install Smart Office client open an Internet Explorer and navigate to https://<load_balancer_address>:port/mango

Smart Office limitations when using a load-balancer

Collaborations does not work properly when using a load-balancer and should be turned off.

Turn off collaborations by setting the property Enable collaboration server to false.



Both M3 UI Adapter and M3 H5 Client Enterprise can be configured as Smart Office server, both be deployed to several hosts and run multiple instances at the same time. The process of deploying the application to another host and configuring the Grid Bindings are exactly the same for both M3 UI Adapter and M3 H5 Client Enterprise.

Securing Smart Office communication with SSL

“Certificates, certificates, certificates! I do not want to hear another word about certificates!”, famous words from a frustrated colleague of mine. But the truth is that understanding how SSL certificates are used to secure HTTP communication is not always easy to understand. Security is always tricky and troubleshooting security issues is always a pain. This article will of course focus on Smart Office but almost everything described is valid for any web application as well.

General SSL information

HTTPS encrypts the traffic between the clients and the server and also prohibits man-in-the-middle attacks. To ensure server identity (prohibit man-in-the-middle attack), the server URL is included in the SSL certificate.

Even though this article is about Smart Office it is easier to troubleshoot and verify SSL certificates through a browser. If the browser can show a HTTPS URL without errors, Smart Office will not have a problem with the URL either.

To view an existing certificate used in a web-site, open up Internet Explorer and navigate to the HTTPS URL. In the example below I have used Google mail.


Click the padlock and then click View Certificates. It look slightly different on different Internet Explorer versions or if using some other browser.


There is some important information on the first tab.

The Issued to: field contains the URL that the SSL certificate is valid for. If accessing the machine through any other URL (IP or only “mail” if you happens to be on the intranet) the browser will report an error. This means that for every server exposing a HTTPS connection a unique SSL certificate must be used. There is however one way to reduce the number of SSL certificates and that is to create a so called wildcard certificate. A wildcard certificate may have an Issued to value like * Such a certificate could be used for all servers in the domain. Using a wildcard certificate is less secure then using unique certificates.

Another feature of SSL certificates that can be useful is the ability to add on alternative names. If a server has one or more aliases in the DNS it is possible to create a SSL certificate that is valid for more than one URL. On the Details tab there may be a field called “Subject Alternative Name” that lists all the server names the certificate is valid for.


The certificate in this example is valid for both and

Now back to the General tab again.

The Valid from, to fields shows the date interval when the SSL certificate is valid. If the SSL certificate has expired the browser will show an error. It is the current date on the client machine that must be in the date interval.

The Issued by: field shows the certificate that has issued (created) the certificate. A self-signed certificate would show the same name in the Issued by: field as the Issued to: field.

On the Certificate Path tab the whole certificate chain is shown.


The top most certificate, “GeoTrust Global CA” in this example, is called the root-certificate and must be in the Trusted Root Certificate Authorities list in Windows. If the certificate is not in the list, the browser will show an error when connecting to the HTTPS URL.


Fortunately Microsoft is maintaining this list for us for all the bigger commercial root certificates and is pushing them out to all Windows operating systems through patches. A root-certificate is always a self-signed certificate.

Short summary on what must fulfilled in order for a valid HTTPS connection.

  • The HTTPS URL must be exactly as the Issued to field or any of the alternative names.
  • The root-certificate must be in the Trusted Root Certificate Authorities list in Windows.
  • The current date of the client machine must be in the Valid from, to interval of both the SSL certificate and the root-certificate.

Note that the port number is not include in the SSL verification, that means that the same SSL certificate can be used for all HTTPS endpoints on a machine regardless of which port they use.

View Windows Certificates

To open the Certificates tool show above, open a CMD window and type mmc.exe and press enter. The Microsoft Management Console should be shown. Select File->Add/Remove Snapin… Select Certificates and press Add, select Computer account and press Next. Select Local computer and press Finish.

Mode of acquisition Advantages Disadvantages
Issued by a third-party vendor. Works for clients from any domain. Additional expense; delivery time gap.
Issued by an in-house certificate authority Inexpensive; automatically applies to all clients in the internal network. Configuration and maintenance of certification server is needed; applies only to domain clients.
Self-signed certificate Inexpensive and easy to use especially for test environments. Must be installed at all client machines. Not secure.

Self-signed certificates are almost never used together with Smart Office and is not discussed in this article.

Recommendations on when to buy or when to use an in-house Certificate Authority comes in the next section.

Infor Smart Office and Infor ION Grid

Infor ION Grid (Grid) is the application container where the Smart Office server is running.

When installing Grid it will actually create its own root-certificate and use that certificate when issuing all other certificates in the Grid, you can say that the Grid has its own Certificate Authority. For each Grid Host there is a SSL certificate created and all Grid Routers on that host will use the same SSL certificate (in future Grid versions there may be an option to change SSL certificate per Grid Router).


In Grid 1.11 the SSL certificates key-stores are located on each Grid Host in the folder <LCM service>\grid\<Grid name>\grids\<Grid name>\secure\ The key-store file-name is https.ks and the key-store password is stored in The key-store is a java key-store that can be manipulated with the JDK tool keytool.exe. The only time necessary to manipulate it manually is when wanting to re-use an existing SSL certificate.

For Smart Office to be able to use an out-of-the-box installation the Grid root-certificate must be placed in the Trusted Root Certification Authorities list in Windows. There is an instruction at the end of this blog post on how to do that.

Using an out-of-the-box installation that requires manual steps to start Smart Office may be cumbersome if having many users. Especially if the users do not have that much computer skills or if the users do not have administrative rights on their computers.

There are a few different ways to make it easier for the users, which way to go depends on how Smart Office is going to be used and the intranet infrastructure already in place at the customer.

  • Is Smart Office going to be used over open internet? If yes, I recommend buying a certificate from a third-party vendor. Securing Smart Office and Grid to be used over open internet requires some serious configuration and is not covered here.
  • Does the customer have an in-house Certificate Authority?
    If yes, use it to create SSL certificates. Both Windows server 2008 and Windows server 2012 comes with a Certificate Authority.
    If no, can the customer install one?
  • As a last way, it is possible to distribute the Grid root certificate through a Windows policy. How to distribute a certificate is describes in the Smart Office administration guide or google it.

There are instructions in the Infor ION Grid Security Administration Guide on how to make a certificate request through the Grid Configuration Manager and how to import the actual certificate after it is created by the Certificate Authority.

Smart Office

Smart Office requires that all communication between the Smart Office client and the Smart Office server is made over HTTPS. Smart Office features, like the M3 MForms and the Lawson SForms, executing inside of Smart Office may or may not require HTTPS even though the recommendation is to always use HTTPS. Each Smart Office Feature normally has its own section in the Profile Editor URLs where URLs to back-end system is configured.

Security considerations

The general recommendation is to use at least 2048-bit key for a SSL certificates but there is more than just the key size that makes a connection secure. Read more in this article

Here are also some other interesting links that can be worth reading.

Appendix: How to install the Grid root certificate

Easiest way of installing and the Grid root-certificate is to go to the Smart Office installation page, normally something like and right-click on the text Install Infor Smart Office and select Copy link address.


Paste the link in text editor and find and copy the value of the SERVER parameter, something like

Start an Internet Explorer as an administrator and navigate to the copied SERVER URL, the Grid information page should be shown and there should be a certificate issue.


Click the Certificate error and click View Certificates, select the Certification Path tab and select the root-certificate and click View Certificate.


In the new Certificate dialog click Install Certificate…. In the Certificate Import Wizard select Local Machine and click Next. Select Place all certificates in the following store and click Browse… In the Select Certificate Store dialog check the Show physical stores checkbox and select Trusted Root Certification Authorities->Registry


Click OK, click Next, click Finish. Click Yes in the Security Warning.
Close all dialogues and all open Internet Explorers. Open an Internet Explorer and try the server URL again, there should be no certificate issues.

Changing Smart Office settings files without Smart Office client

From Smart Office 10.0.3 all settings files are located in the GDBC database instead of the file system. Sometimes an administrator needs to change a setting without opening the Smart Office client. In Smart Office 10.0.5 there is an external tool called SettingsTool.exe that can be used to access the settings files on the server. Continue reading

LSO and Grid Application Discovery Service

In LSO 9.1.3 we moved the server to the Grid. There is a discovery service for LSO SDK applications (features) and Mashups that have a need to communicate with a Lawson Grid application. The discovery service reduces the configuration that needs to be added to the feature or mashup, e.g. no System Profile information needed in the manifests. This also means that there will be less work for the installer/administrator to configure installed applications. The discovery service can be used to retrieve the base URL to the Lawson Grid Application. Continue reading