TN - IT09112611 - Synchronizing Alarms Between Multiple InTouch WindowViewer Sessions on Different Computers

• Document Version: 001
• Applies to Version(s): AVEVA InTouch 2020 and later | Standalone and Managed InTouch Applications

Overview

This tech note explains how to configure multiple AVEVA InTouch nodes so alarms and acknowledgements are synchronized between WindowViewer sessions running on different computers.

This applies to standalone or managed InTouch applications using local tag-based alarms where one WindowViewer node should act as the alarm provider and the other node(s) should view and acknowledge those alarms remotely in synchronization with all nodes in the environment.

Important Concept

Each WindowViewer node has its own independent alarm engine. If each node generates its own local alarm independently, the alarms are not automatically synchronized between computers.

To synchronize live alarms and acknowledgements, configure one node as the alarm provider and subsequent nodes to query alarms from that provider.

Note: Alarm history logging tools such as Alarm DB Logger do not synchronize live alarms. They only record alarm history.  Live alarm synchronization requires the provider/consumer architecture described in this tech note. 

Recommended Architecture

The examples in the article use the following environment. Substitute your own node names when following the steps.

Use one primary WindowViewer node as the alarm provider. All other nodes consume alarms from that provider via an alarm query pointing to the alarm provider. 

Example:

Primary Alarm Node:

Computer: LAB-GR01
Application provider: InTouch
Alarm group: $System

Remote Alarm Viewer:

Computer: LAB-VIS01
Alarm query points to LAB-GR01

Example alarm query:

\\LAB-GR01\InTouch!$System

The examples in this article use the .NET Alarm Client control. The alarm query is configured as part of the application and is used by whichever computer is running the application. The same query syntax applies to other alarm controls, although the configuration location may differ.

In this example, the alarm query always references LAB-GR01 as the alarm provider. Therefore, regardless of whether the application is running on LAB-GR01, LAB-VIS01, or another node, the Alarm Client retrieves alarms from LAB-GR01 until the query is modified.

Multiple Alarm Providers

The examples in this tech note use a single alarm provider because it is the simplest architecture to configure and troubleshoot.

InTouch also supports environments with multiple alarm providers, where each WindowViewer node generates its own alarms while alarm clients query multiple providers simultaneously.

For example:

\\LAB-GR01\InTouch!$System \\LAB-VIS01\InTouch!$System \\LAB-VIS02\InTouch!$System

In this configuration:

• Each provider owns the alarms it generates.
• The alarm client displays alarms from all configured providers in a single alarm display.
• The Node column identifies which provider generated each alarm.
• Alarm acknowledgements are automatically routed back to the provider that owns the alarm.

Configuration and troubleshooting of distributed alarm provider architectures are beyond the scope of this document. This tech note focuses on troubleshooting communication and synchronization between WindowViewer clients and a single alarm provider but the same principles can be easily adapted for a multi alarm provider environment.

Windows Session / Alarm Manager Requirement

For remote alarms to work properly, alarmmgr.exe  must be running, and the AlarmMgr provider must be registered correctly with the Wonderware SuiteLink service (SLSSVC).

It is important to note that alarmmgr.exe is not a standalone Windows service. It is automatically launched by WindowViewer as a child process when WindowViewer starts. If WindowViewer stops or crashes, alarmmgr.exe will also stop. AlarmMgr cannot be started or managed independently.

When WindowViewer is launched through an RDP session, alarmmgr.exe may register with an IP address appended to its name rather than registering as plain AlarmMgr. Remote nodes cannot locate AlarmMgr in this state and the remote alarm query will return no alarms. 

To determine which Windows session WindowViewer is running in, run the following command on LAB-GR01:

query session

Review the SESSIONNAME column:

For interactive WindowViewer applications, the alarm provider should run from the console session. If WindowViewer is configured to run as a Windows service, alarmmgr.exe runs in Session 0 by design. Avoid using an RDP session as the alarm provider, as AlarmMgr may register with a session-specific name that remote clients cannot resolve.

To confirm alarmmgr.exe is running, use:

tasklist | findstr /i "alarm"

Task Manager will also show alarmmgr.exe running under the expected account (NT SERVICE\VIEW by default).

Now confirm AlarmMgr is correctly registered with SLSSVC:

slsping localhost alarmmgr

A successful result confirms that Alarm Manager is registered locally with SLSSVC:

An unsuccessful result indicates that the Alarm Manager provider is not currently registered or cannot be reached through SuiteLink:

Note: If Alarm DB Logger has been configured to run as a service, there will be a second instance of alarmmgr.exe. If Alarm DB Logger is not running as a service, there will typically be one instance: 

Please note that SLSSVC cannot register more than one application with the same name. If Alarm DB Logger is configured to run as a service, the following registry setting may be required:

HKLM\Software\Wow6432Node\Wonderware\Alarm Manager

Create or verify the following DWORD value:

Session0LegacyMode  

• Set to 0 only when WindowViewer runs in the console session and Alarm DB Logger runs as a service. This allows the session 0 instance to register as AlarmMgr0 while the console session instance registers as AlarmMgr, so both can register successfully. 
• Set to 1, or remove the value entirely, when WindowViewer itself runs as a Windows service on the alarm provider node. 

Important: Do not set Session0LegacyMode to 0 if you intend to run WindowViewer as a service on the alarm provider node. With Session0LegacyMode set to 0, the WindowViewer service's AlarmMgr (Session 0) will register as AlarmMgr0 instead of AlarmMgr and remote alarm queries will fail to connect. 

When WindowViewer runs as a Windows service and acts as the alarm provider, Session0LegacyMode must be set to 1 or the registry value must be removed entirely, depending on the desired configuration. These settings are mutually exclusive and cannot be used together on the same node. If both WindowViewer and Alarm DB Logger need to run as Windows services, configure Alarm DB Logger on a different node.

For more information about running WindowViewer as a Windows service, see Configuring WindowViewer as a Service and Resolving Remote Historian Connectivity Issues in the Related Articles section below.

Configuration Steps:

Step 1: Open the application from the primary alarm node

On LAB-GR01, open the InTouch application in WindowMaker. 

Step 2: Verify alarm configuration

Verify alarms are enabled for the desired tags:

 Tagname Dictionary > Alarms

Configure additional alarm settings in WindowMaker Backstage > Configure > Alarms

Step 3: Start WindowViewer on the primary alarm node 

Start WindowViewer on LAB-GR01. 

Confirm that alarmmgr.exe is running under the configured account.

The Operations Control Management Console (OCMC) will indicate that AlarmMgr has been successfully registered with SLSSVC.   

The following command can be run on LAB-GR01 to confirm AlarmMgr has been successfully registered with SLSSVC:

slsping localhost alarmmgr

Once everything is registered and running, WindowViewer should now display current alarms on LAB-GR01 in the Alarm Client Control.

If alarmmgr.exe does not register correctly with SLSSVC in the console session, the OCMC will log a message similar to the message below:

The slsping command will also indicate that AlarmMgr is not registered. 

If Alarm Manager is running in Session 0 and Session0Legacy mode has not been enabled, the following message will be logged to the OCMC. In this configuration, AlarmMgr will not register with SLSSVC and alarms will not be accessible from remote nodes. 

Step 4: Confirm connectivity to Alarm Manager from the remote node

From LAB-VIS01, confirm that the primary node's Alarm Manager is reachable across the network: 

slsping LAB-GR01 alarmmgr

If this command fails, confirm name resolution, firewall rules, SuiteLink communication, and that AlarmMgr is correctly registered on the alarm provider node. 

Step 5: Start WindowViewer on the remote node 

Start WindowViewer on LAB-VIS01.

Confirm that alarms from LAB-GR01 appear in the alarm display. The Node column should identify LAB-GR01 as the alarm provider.

Step 6: Test Acknowledgement Synchronization 

Generate a test alarm on LAB-GR01. 

Acknowledge the alarm from LAB-VIS01.

Confirm that acknowledgement is reflected in the primary node and any other nodes consuming alarms from the same provider.

“Alarms acknowledged from LAB-VIS01. The acknowledged state is reflected on LAB-GR01”

Troubleshooting

If alarms appear locally but not remotely, check the following:

• Confirm the remote alarm query uses the correct computer name and provider syntax.
• Confirm the primary node can be resolved by hostname.
• Confirm both nodes can communicate over the network.
• Confirm Windows Firewall or security software is not blocking SuiteLink communication, confirm TCP port 5413 is open between nodes. 
• Confirm SuiteLink service is running before alarmmgr.exe starts.
• Confirm alarmmgr.exe is running on the alarm provider node.
• Confirm AlarmMgr is registered as AlarmMgr and not with an appended IP Address (for example AlarmMgr254.128.0.0)  or session-specific name such as AlarmMgr0. 
• Avoid testing from an RDP session.
• Restart SuiteLink, WindowViewer, and alarmmgr.exe in the correct order if needed.

Recommended restart order:

1. Stop WindowViewer.
2. Stop alarmmgr.exe if it remains running.
3. Confirm SuiteLink service is running.
4. Start WindowViewer from the console session (or as a service).
5. Confirm alarmmgr.exe starts and remains running.
6. Confirm slsping localhost alarmmgr succeeds on the provider node.
7. Confirm slsping <ProviderNode> alarmmgr succeeds from the remote node.
8. Retest the remote alarm query.

Terminal Server or session-specific environments may require additional session-specific syntax depending on the InTouch version and deployment type. If alarms work locally but not remotely in an RDP or Terminal Server environment, confirm which session is hosting alarmmgr.exe and whether the remote clients are querying the correct alarm provider/session.

Notes:

The alarm provider should be treated as the source of truth for live alarm state.

If multiple nodes are configured to generate the same alarms independently, acknowledgements may not synchronize because each node owns its own separate alarm state.

For synchronized alarm viewing and acknowledgement, configure remote nodes to consume alarms from the primary alarm provider rather than generating duplicate independent alarm states.

Related Articles

Configuring WindowViewer as a Service and Resolving Remote Historian Connectivity Issues
https://knowledge.insourcess.com/aveva-intouch-tech-notes/running-windowviewer-as-a-service-an-troubleshooting-connection-issues-to-a-remote-historian

Windows Commands for Testing SuiteLink Communications
https://knowledge.insourcess.com/aveva-communication-drivers-tech-notes/essential-windows-commands-for-aveva-ot-environments

TN IT136 - Configuring InTouch to Communicate with WindowViewer in a Terminal Server Session
https://knowledge.insourcess.com/aveva-intouch-tech-notes/tn-it136-configuring-intouch-to-communicate-with-windowviewer-in-a-terminal-server-session

                               _____________________________________________________________________________________________________