"No Engines are Available" Troubleshooting Guide

Jacob_Eastman

This is one of the most common errors found in BPM. The basic idea is that the Web front end cannot find any Engine back end to connect to. This can happen even on an all-in-one server. Below is the error in BPM v9.2:

 

Central to this is the EngineServiceConfig.xml located in the IIS Extensions directory. This file controls the method with which the web site connects to the engine. Note that the web.config for the web front end controls the location that the EngineServiceConfig is loaded from so it may not be the default location especially in a multi-system environment.

There are two main methods: "TCP" connection over port 4001 and "HTTP" over port 80 using IIS. Below are examples of each from a EngineServiceConfig.xml.

       
            
                
                    tcp://HUMPHREY:4001/ECL
                
            
        

       
            
                
                    http://HUMPHREY/BPMEngine.NET/ECL.rem
                
            
        

Generally the TCP method will not cause this error unless the machine name it points to is incorrect or port 4001 is not open.

The HTTP is required for Single Sign On and is sometimes preferrable when ports are restricted to only common ports such as 80, but it is also the likely cause of the error as it requires more configuration to work correctly.

As a number of things can cause the error with HTTP, the IIS logs are helpful in diagnosing the issue. These will be located on the Engine server and by default on IIS 7 they will be in C:\inetpub\Logs\Logfiles\W3SVC\.

The line to look for is the POST to the BPMEngine.NET which will look like this:

2012-02-08 20:17:09 192.168.1.1 POST /BPMEngine.NET/ECL.rem - 80 - 192.168.1.2 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+6.1.7600.0;+MS+.NET+Remoting;+MS+.NET+CLR+2.0.50727.4963+) 200 0 0 335

The first thing to look for is the HTTP response code which is near the very end of the line. In this case it is a 200.0 OK.

There are 3 main response codes to look for and each has a different cause.

The most common is the 401 Unauthorized. This is caused by the BPMEngine.Net virtual directory's authentication settings. When setting up SSO this virtual directory is set to use Windows Authentication and the end user's credentials must make it to the engine for the login to succeed. If credentials do not make it to the engine you will receive a 401 response code. A working SSO POST should look like this:

2011-08-10 17:01:51 192.168.1.1 POST /BPMEngine.NET/ECL.rem - 80 HUMPHREY\Administrator 192.168.1.2 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+6.0.6001.65536;+MS+.NET+Remoting;+MS+.NET+CLR+2.0.50727.3053+) 200 0 0 237

Notice the user credentials passing to the engine, in this case HUMPHREY\Administrator. An initial 401 occurs before the successful POST to tell the client to pass credentials and is expected.

The next most common response code is a 500 Internal Error. This most often caused by a configuration issue in IIS with either the application pools or the web configs. One thing to check is that the BPMEngineDotNetApplicationPool is set to "Enable 32bit Applications - True". Another thing to check is that the URL in the EngineServiceConfig.xml is spelled correctly. For example, a POST to the BPMNgine.NET directory will result in a 500 error.

Finally, the 200 OK response. This is not an error so it states that the POST was successful meaning the problem causing the "No Engines Available" lays further on in the system. This leads to the COM+ Application. Open Component Services and drill down to the Metastorm Process Engine under COM+ Applications. Continue down to Components and then the Metastorm.EngineEclEndpoint which contains the HTTP connection methods. Right click and go to properties. Under the Security tab it should have "Enforce component level access checks" enabled and the Client role selected. This limits access to the component to processes which have an identity listed under the Client role.

Next, drill down through the Roles to the Client role. The identity of your application pools must be listed here. By default, the identity will be "network service" which you can add to the role or you can change the identity of the application pools to use the service account that the engine runs as.

On Server 2008 R2 machines there is a where the installer will sometimes separate out the Metastorm.EngineEclEndpoint component and place it under a different COM+ Application. In this case, right click on it and select "Move" to move it to the Metastorm Process Engine COM+ Application.

Note that these are only the most common causes for this error. Other issues that disrupt communication between the web client and engine may result in this error message.

Jacob_Eastman

If the above guide does not solve your issue, I would recommend contacting support. Include your server configuration (separate web server vs. all in one), whether this is an upgrade or fresh install, and the POST to the BPMEngine.NET from your IIS logs.

Michael_Turek

If you don't mind me adding this:

 

May sure the identity of MetastormEngineDotNetAppPool matches the identity of the Metastorm service.

 

The identity of the app pool seems to get reset after any update or hotfix.

Jacob_Eastman

Actually, the MetastormEngineDotNetAppPool doesn't need to match the identity of the service. It only needs to be listed under the Client role in COM+ Applications as per my screenshots above.

 

The confusion is that when you install BPM you supply the service account and this is added to the Administrator COM+ role as well as the Client role. Network Service is also added unless you are running Server 2008 R2. Even if you are running R2, you can manually add Network Service to the Client role as detailed above and you can then leave your application pools running as Network Service.

 

Some of our customers require the app pools to run as Network Service or even a separate locked down account due to security requirements so this is highly configurable.

 

As far as best practices, I would recommend adding Network Service to the COM+ role instead of running the app pools as the service account. This makes it so that IIS doesn't need to be additionally configured and it keeps the high permission levels required by the engine from also running as a website.

 

 

Michael_Turek

When I recently updated to 9.2.1 it reset the app pool identity back to network service which was confusing when trying to figure out why "No Engines are Available".  We are running 2008 r2 and the only account we have added was the service account the engine runs under to that client role.

 

This a good information and thanks for the clarification.