Charles Vance Certified Archestra Developer and Freelance Programmer

Tutorial Complexity

What To Do When the Archestra Intouch® Alarm Banner Stops Working

If you or your users have ever experienced a situation where the alarm banner is totally empty of ANY alarms and you KNOW there are alarms active, your system may experiencing an unintended consequence of session zero isolation.  You can reboot the HMI and sometimes that might work but usually the only way to fix this issue is to re-deploy the view app but eventually the HMI seems to do it again at random times. What is going on?

Starting with Windows Vista, Microsoft implemented Session zero isolation, meaning Windows services (System Platform) may only use session zero while GUI’s (Intouch® View) can never run in session zero. Microsoft did this to improve security making it more difficult for malware coming in via the user interfaces to attack operating system components.

However, what this created for Archestra® deployments is a situation where the Intouch alarm manager and the system platform alarm manager race each other to the door. Sometimes the legacy alarm manager wins the race leaving our Archestra® alarm manager out in the cold and the empty alarm banner is the result.

There are other reasons for alarms not displaying properly (i.e., platform alarm provider checkbox not checked, corrupted Intouch installation, etc.) but this is the most common reason and has a quick fix via a registry edit which should be a part of your implementation plan in any case.

If you see an entry in the SMC logger like this: Unable to register. SLSSVC does not support two instances of AlarmMgr with the same name. Please see the Tech Note about configuring Windows Vista and later to support both InTouch and AppServer alarms on the same computer.”

It's a dead give away that this is what is causing your alarm banner to be empty. Unfortunately, this message isn’t always present when the session isolation problem is in action.  Other logger messages indicating alarm manager not connected to the galaxy may point you in the right direction as well, but the best bet is to just apply the registry fix as a preventative measure.

Wonderware® implemented hot fixes for the issue but I have personally seen this problem continue to present itself in version 2014, 2014 R2 and 2014 R2 with patch 2.

The solution?  Apply Tech Note 570.

If you are a registered user of the Wonderware development website then you can find Technote 570 here.

While there is a hotfix that will apply the necessary registry edit to incorporate the fix is a relatively simple manual edit to the registry that can be implemented with a few minutes of work.

CAUTION: Always backup your computer hard drive before making any changes to the registry!

The first step to making the registry edit is to determine if your operating system is 32 bit or 64 bit. The easiest way to find that information is to right click the Computer item on the Windows Start menu, the image below is what should appear:

As you can see, my computer is a 64 bit operating system. This let’s me know which location I will need to make the registry edit to fix this problem.

The solution that Wonderware came up with is to add a new DWORD key named Session0LegacyMode set to equal zero for system platform or 1 for legacy operation.

On 32 bit systems navigate to the registry path for the Alarm Manager at:

HKLM\Software\Wonderware\AlarmManager

64 bit systems navigate to the following location:

HKLM\Software\Wow6432Node\Wonderware\AlarmManager

When you have browsed to the correct location make sure the Session0LegacyMode key is set to zero if using system platform, if the key isn’t there you will need to add it by right clicking and selecting “New/DWORD”

When you finish it should look like this:

Now that’s all there is to it!

Except… what if you are in a production environment with a couple hundred view apps deployed and each deployed computer is in use and cannot be interrupted? Not to mention that if working remotely you will need to login to each computer take the Intouch view offline and navigate around to get this registry edit completed? What then? Since all deployed platform view nodes will need this registry edit it could take weeks to do them all.

There is a better method. first obvious thought might be to do a remote registry edit, or perhaps use power shell, but what if the corporate firewall rules prevent those type edits across the network? What then?

What I did was to create an object that uses a script to execute a batch file on its platform that automatically creates the Session0LegacyMode DWORD key for you. I also added another script to check to see if the Session0LegacyMode key already exists and what it’s value is. Each script is triggered by attributes using the object viewer giving you complete control of the process.

STEP 1:  Create the batch file that will be copied into a temporary location on the target computer hard drive, somewhere we can easily trigger it from a deployed object, I chose to place the batch file on the C:\ Drive then deleted it when finished. I created two batch files, one for 32 bit edits and the second for 64 bit edits.

The 32 bit batch file is named Session0LegacyMode.bat and when opened using notepad it loooks like this:

The 64 bit version of the registry edit batch file looks like this, notice we added "Wow6432Node" in the registry file path :

STEP 2: Create an object template for the deployed registry edit management.
The $Session0LegacyMode object template is derived from the $UserDefined template with the following scripts and attributes.
Attributes:
b_AddKey Boolean
b_GetMode32 Boolean
b_GetMode64 Boolean
s_SessionValue String

Scripts:

AddKey Script 

AddNode32 Script

AddNode64 Script

After building the SessionLegacyMode template to use it create an instance and deploy it to the platform where you need to modify either check for the Session0LegacyMode key or add one if it doesn't exist.

Then move the Session0LegacyMode.BAT file to the C:\ Drive of the Computer hosting the platform.

Right click the deployed object and select the "View in Object Viewer" option.

When the object viewer appears it will take a few seconds to fully discover the path to your object be patient allowing the auto-discovery process to finish. When it stops the contents to our Session0LegacyMode object will be in the contents window. Now locate and drag and drop  each of the user defined attributes created in the object into the watch window (or right click selecting "Add To Watch"). See graphic image below:

Once the attribute is in the watch window double click it or Select "Modify" from the right click options then select "true" and click "apply". This will execute the batch file we placed in the C:\ drive inserting the new key. 

When complete the attribute will automatically return to false condition, this may take a few seconds. If it does not automatically return to false make sure the batch file is in the right place.

To check the registry remotely click the b_getMode64 (if 64 bit OS) and repeat the process. Select "true" and click "apply".

If the add key operation was successful the s_SessionValue will indicate a "0". 

Checking the registry before the b_AddKey attribute is set retrieves the value in the Alarm Manager registry, if the key is not present the attribute will not return to zero.

The image below shows what the object viewer looks like after a successful key insertion and check using the b_GetMode32 attribute.

Clicking the download button gives you the Session0LegacyMode template as an aaPkg file with registry batch file and all scripts as text files.

If this tutorial has been helpful to you please tell a friend. Find the video version of this tutorial on my You Tube channel.

If you are interested in learning more about Archestra Enroll in my Free Course by clicking the button below.

Step-by-Step Archestra Scripting Guide

Subscribe now to receive FREE Tutorials and Scripting Examples

We will never share or sell your email address.

Powered by ConvertKit

No comments yet

Leave a Reply: