- Login to ITSM-Suite
- Open the AtriumCore Console
- Open the Atrium Explorer
- Click “find” and search for a CI (for example we use the name “servername.customername.com:os-environment”)
- Drop it to the sandbox
- Kill the AIS (Atrium Shared) plugin.
. Click on simulate impact.

The communication between MidTier and the filter-plugin isn’t stateless. It uses a cache mechanism to setup and start the simulation. As soon as one later call doesn’t get to the same server or the same plugin, the filter-plugin at this “newly involved” server doesn’t know anything about the beforehand initialized simulation on the other server. An error is the result.

This is true for version 7.6.04SP4 or below, 8.0 and 8.1.


LP: BMC Atrium CMDB Suite

 

Legacy ID:KA408259

In 7.6.04 you can apply SP5 which resolves the issue.
Versions 8.0 and 8.1 do not have fixes as of today. The architecture of the AIS plugin has changed in these versions, shitfing from a regular plugin to an ARDBC plugin. This means the plugin has a local cache, if the user logs into server 1 and starts a simulation, and later on he tried to add a new CI to the simulation, but this time server 2 got the request, the server 2 plugin will not know how to process the request.

To work-around this limitation in AIS you need to reconfigure your AIS plugin entries in the ar.cfg files of all your servers in the group so that they all point to the same server, then only one server in the server group will handle the AIS actions:

In 7.6.04SP4 or below:
Server-Plugin-Alias: AIS.FILTERAPI AIS.FILTERAPI <OnlyServerTakingAISRequests>:9556

So for ex. if I have a Server Group with Server 1 and Server 2. I chose Server 2 to take all AIS requests.
As such I edit the ar.cfg in server 1 and modify the line to look like this:

Server-Plugin-Alias: AIS.FILTERAPI AIS.FILTERAPI SERVER2:9556

In 8.x or above the plugin alias looks like this:
Server-Plugin-Alias: BMC.ARDBC.ATRIUM.AIS BMC.ARDBC.ATRIUM.AIS <OnlyServerTakingAISRequests>:9556