Operating System, ​.NET framework, and virtualization requirements

This section describes additional details about the supporting software for an InTouch HMI system.

Software requirement notes

Windows Operating System notes

• Windows versions 8.1, and 10 support touch screen gestures. In the Windows version 8.1,if the user swipes in from the right edge of a touch screen with a finger gesture, a set of Windows charms appears, which includes Search, Share, Start, Devices, and Settings. Moving the mouse cursor to the upper-right corner of a screen also shows the Windows charms for non-touch screens.

  Showing the set of charms is a standard feature of Windows versions 8.1 that cannot be disabled by software for a touch screen. As a result, operators can access these Windows charms and possibly unlock a dedicated touch screen view node.

• Newer operating system Service Packs (SPs) than those listed do not block the installation of products. A warning message may appear during the installation process.

• The Galaxy Repository (GR Node) can run on a client Windows operating system in a configuration in which System Platform products are installed on up to five nodes. For a system with more than five nodes, the Galaxy Repository must be installed on a computer running a Windows Server operating system.

• Development and application nodes are considered to be clients of the server GR node.

• When an operating system is upgraded on a computer, existing System Platform products must be uninstalled prior to the upgrade and then reinstalled after the upgrade. There are three exceptions. System Platform products do not need to be uninstalled when upgrading from:

  • Windows 8 to 8.1

  • Windows 8.1 to 10

  • Windows 2012 to Windows 2012 R2

.Net notes

• Versions of .NET (other than 4.x versions) can coexist, but all .NET code, including QuickScript.net scripts, run under .NET 4.8.

  For more information about .NET Framework requirements and compatibility, see .NET Framework Requirements and Compatibility .

• .NET 3.5 is installed only because the supported SQL Server versions require it. No other dependencies must exist.

Operating System notes common to AVEVA products

ActiveX Controls behavior on supported Windows Operating Systems

Due to the Data Execution Prevention (DEP) feature of Windows 7 and later operating systems, any ActiveX control built with ATL version 7.1 or earlier will fail to host or will have unpredictable behavior in InTouch 2017 UPDATE 1 either in WindowMaker or WindowViewer. For more information, refer to Tech Note 922: "Some ActiveX Controls NOT Supported in InTouch 2012 R2 (Version 10.6)" available from the Technical Support web site.

Configuring remote alarm retrieval queries

The process to configure remote alarm retrieval queries has changed for interactive applications such as InTouch HMI when running on currently-supported Windows and Windows Server operating systems.

When InTouch WindowViewer is started and generates alarms from an interactive Windows desktop session, an AlarmViewer control (running within InTouch HMI) on a remote node must be specially configured to query the alarms. The source alarms will not appear unless the AlarmViewer control's alarm query is configured.

This type of query only works for InTouch HMI as an alarm provider running in a Terminal Services session, not for InTouch HMI running in a console session.

Configure the AlarmViewer's alarm query

1. After starting InTouch WindowViewer (alarm provider), open the Operations Control Logger and look for the most recent string generated by AlarmMgr. For example: "Registering AlarmMgr with SLSSVC as AlarmMgr 253.127.148.120". The indicated IP address will be unique to your alarm-providing node. Note the IP address for Step 2.

2. In the Alarm Query tab of the AlarmViewer control on the remote computer, configure the alarm query as follows, substituting your nodename of the alarm providing InTouch HMI for "nodename" below and substituting your IP address noted in the previous step:

   \\nodename:ip_address\intouch!$system

   where nodename is the name of the node that is providing the InTouch alarm and ip_address is the IP address that you determined in step 1.

3. Test to validate that the alarms generated from the alarm-providing node are shown accurately in the AlarmViewer control.

Using Alarm Manager on a Single Node Running Both InTouch HMI and Application Server Alarm Providers

Starting with Microsoft Windows Vista, the operating system imposes "Session 0 Isolation" as a security enhancement. All Windows services and associated programs are required to run in Session 0, and no GUI applications are allowed to run in Session 0.

Prior to Windows Vista, Application Server and InTouch HMI WindowViewer ran in the same Windows session. Session 0 Isolation requires that Application Server and WindowViewer run in separate Windows sessions. Alarms that are reported by the Galaxy are handled by the Session 0 instance of Alarm Manager (AlarmMgr), which is now different from the Console Session instance of AlarmMgr that handles InTouch alarms. A simple alarm query in an InTouch alarm display such as

\InTouch!$System \Galaxy!Area_001

is now serviced by two separate instances of AlarmMgr -- one running in the Console Session for InTouch, another running in Session 0 for the Galaxy.

This behavior, and related behaviors and error messages resulting from the Windows operating system Session 0 changes, along with procedures to configure the Distributed Alarm System to support alarms from both InTouch and Application Server on the same computer node running with Windows Vista and later operating systems, are described in detail in TechNote 988, "AlarmMgr Support for InTouch and AppServer on Windows Vista and Later". You can download this TechNote from the Global Customer Support (GCS) website.

Remote Desktop Services (Terminal Services) behavior in Windows Server Operating Systems

Windows Server 2008 R2 and later Windows versions no longer support the /console switch as a means of starting the remote desktop (RDP) client, also known as Session 0 or Terminal Server Console session. In Windows Server 2008 or later, Session 0 is no longer an interactive session, and is reserved only for Windows services. From Windows Server 2008 and later, all remote connections are treated as remote RDP sessions regardless of /console, /admin, or any other switches used to make the connection.

This impacts InTouch HMI functionality such as Alarm Manager that depends on the Remote Desktop (Terminal Server Console) session.

In another aspect of Remote Desktop Services behavior, InTouch HMI functions such as TSEGetClientID() can return a null value with InTouch running in a remote desktop (RDP) client session. The cause of this behavior is that the relevant roles are not installed on the RDP client. You must install the "Remote Desktop Host" role in order for TSEGetClientId() and other related functions to work properly.

The impact to Application Server is minimal as most Application Server processes run as services. One impact to Application Server is to carry forward the restriction introduced with the Windows Vista operating system which permits only one alarm provider. While both Application Server and InTouch HMI can be configured as alarm providers, only one alarm provider can be configured at any one time.

Application Server and InTouch HMI detect when the application is running in the console. In Windows Server, it implies that the application was started by a user physically at the machine. However, this behavior may require you to disable the group policy that enables Fast User Switching.

The software detects when an application is running in the console. All remote connections are treated as a remote RDP session by Windows Server, regardless of /console or /admin switches in the mstsc connection.

To disable fast user switching through the Group Policy interface

4. Click Start and then Run. The Run dialog box appears.

5. Enter gpedit.msc and click OK. The Group Policy dialog box appears.

6. Go to the following location: Local Computer Policy > Administrative Templates > System > Logon.

7. Set Hide Entry Points for Fast User Switching to Enabled. Enabling this policy hides the Switch User option in the Logon interface, the Start menu, and the Task Manager.

8. On the File menu, click Exit to close the Group Policy dialog box.

By enabling the policy, Administrators hide the Switch User button in Windows logon, in the Start menu, and in the Task Manager.

InTouch HMI Operating System notes

• Windows client (starting with Windows 7) do not support a dedicated single-node server configuration that runs one or more databases for an InTouch HMI system.

• The EnableDisableKeys() function writes to the Windows registry to enable or disable some keys on the host computer running an application in WindowViewer. For security purposes, Windows 7 and later versions of Windows prevent Standard or Power users from writing to the registry. Windows Administrators can write to the registry if not disabled by local domain security policies.

  You can configure local Windows security policies that work in conjunction with the EnableDisablekeys() script function to regulate the user's access to keys in a running InTouch application.

• As of System Platform 2014, a computer running Windows 7 or later operating systems can be configured as both an InTouch and an Application Server alarm provider. For more information, see Using Alarm Manager on a Single Node Running Both InTouch HMI and Application Server Alarm Providers on Windows Vista and Later Operating Systems.

  The following InTouch legacy script functions do not operate on 64-bit versions of Windows: WWPoke(), WWExecute(), WWRequest(), ActivateApp() and SendKeys().

• The InTouch Extensibility Toolkit might need to be started by right-clicking and selecting Run As Administrator on Windows 7 or later operating systems to function properly.

• The onscreen keyboard options have changed, beginning with Windows 7 and Windows Server 2008 R2 operating systems.

• Hovering to select from the Windows keyboard does not work in supported versions of Windows operating systems.

InTouch HMI View Applications and DDE support

NetDDE is not supported for InTouchView applications.

By design, an InTouchView application does not serve data to any other source, including InTouch HMI itself. When WindowViewer starts, it verifies if the application is an InTouchView application. When WindowViewer detects an InTouchView application, it does not register to become a DDE server. Industrial Graphics make use of the client layer when accessing InTouch tags, and appear as a third-party client trying to access WindowViewer as a data server. As a result, Industrial Graphics cannot communicate with InTouch tags when used with an InTouchView license.

In Industrial Graphics, InTouch:‹tagname› is still a valid method of referring to an InTouch tag on a local node.

InTouch HMI support for Windows user account control

System Platform 2023 R2 SP1 with InTouch HMI supports User Account Control-enabled operations on run-time nodes.

.NET Framework requirements and compatibility

IMPORTANT: System Platform 2023 R2 SP1 installs .NET 4.8 if the currently installed version of .NET is 4.7.2 or lower. If .NET 4.8 or later is installed, no change is made to the .NET Framework. Prior to upgrading your existing applications to System Platform 2023 R2 SP1, we strongly recommended that you:

• Back up your applications

• Familiarize yourself with the changes introduced by Microsoft in the .NET Framework

• Review your .NET scripts and .NET controls for any required changes

After upgrading to System Platform 2023 R2 SP1, you should perform application testing on application scripts and on script libraries used by the application to ensure they continue to function properly under .NET 4.8. We also recommend you test the upgrade in a staging system prior to upgrading your production system.

System Platform 2023 R2 SP1 leverages Microsoft .NET Framework 4. The System Platform installation program will install .NET 4.8 if your system uses version 4.7.2 or lower. No change is made if your system uses .NET 4.8 or higher. Multiple versions of the .NET Framework can coexist. On nodes where SQL Server is installed, .NET 3.5 is also installed by System Platform to support SQL Server. In this scenario, other applications you have on the same machine with dependencies on .NET 3.5 will access .NET 3.5. System Platform 2023 R2 SP1 will use .NET 4.7.1, 4.7.2, or later.

All user-supplied .NET code that runs in the context of InTouch HMI and Application Server requires .NET Framework 4.8 or higher. Although .NET Framework 4.5.1 (and later) is highly compatible with applications that are built with earlier .NET Framework versions, you may have to update your scripts, if your .NET scripts were created prior to System Platform 2014. These changes may also affect .NET controls developed with .NET 3.5.

In application scripting, some .Net codes could fail if not using proper text encoding, and could cause a script to exit without completion. The UTF8Encoder is the default BinaryStream decoder in .Net 4.5. To enable an application script to decode ASCII XML data, for example, insert the following snippet:

BinaryReader streamReader = new BinaryReader(ms, new ASCIIEncoding());

To learn more about changes introduced in different versions of the .NET Framework, refer to the following Microsoft resources:

What's New in the .NET Framework: http://msdn.microsoft.com/en-us/library/ms171868%28v=vs.110%29.aspx

What's obsolete in the .NET Framework Class Library: https://msdn.microsoft.com/en-us/library/ee461502%28v=vs.110%29.aspx

Migration Guide to the .NET Framework 4.6 and 4.5: https://msdn.microsoft.com/en-us/library/ff657133%28v=vs.110%29

.NET Framework 4 Migration Issues: http://msdn.microsoft.com/en-us/library/ee941656%28v=vs.100%29

Virtualization host support

See the Global Customer Support (GCS) Technology Matrix for supported virtualization environments.