Skip to main content
InSource Solutions

Wonderware Software Requirements (OS, SQL, etc)

insource_logo_large.jpg                                    TECHNOTE

Author

Mike Viteri, Glenn Yancey

Publish Date 7/30/13

Applies to Software

ALL

Applies to Version

2012 R2

Applies to System/Module

 

Article Version

1.00.02

 

Problem Statement

 

Operating System Requirements not listed in one document for Wonderware Products

Solution Details

Hardware Requirements to be listed in a separate tech note
 
Notes:
  • Wonderware does NOT support Domain Controller OS Configurations on the same machine as Wonderware.
  • The entry for Wonderware Application Server applies to the ArchestrA IDE (Development node) and ArchestrA Run time (Application node).
  • The Galaxy Repository (GR node) can run on a client Windows operating system only in a single-node scenario.
  • Development and application nodes are considered to be clients of the server GR node.
  • Other .NET Framework versions can coexist, but all scripts in objects run in .NET Framework 4.0. For more information about .NET Framework requirements and compatibility, see .NET Framework Requirements and Compatibility

 

Summary of Requirements for ArchestrA System Platform 2012 R2 (3.6)

The following table lists the operating system, .NET Framework, and virtualization requirements for ArchestrA System Platform 2012 R2.

 

TN_OSRequirement1.jpg

Notes:

  • The entry for Wonderware Application Server applies to the ArchestrA IDE (Development node) and ArchestrA Run time (Application node).
  • The Galaxy Repository (GR node) can run on a client Windows operating system only in a single-node scenario.
  • Development and application nodes are considered to be clients of the server GR node.
  • Other .NET Framework versions can coexist, but all scripts in objects run in .NET Framework 4.0. 

Operating System Notes: Common for Wonderware Products

ActiveX Controls Behavior on Windows 7 and Windows 2008 R2 Operating Systems

Due to the Data Execution Prevention (DEP) feature of Windows 7 or Windows 2008 R2 operating systems, any ActiveX control built with ATL version 7.1 or earlier will fail to host or will have unpredictable behaviors in InTouch 10.6 either in WindowMaker or WindowViewer running on Windows 7 or Windows 2008 R2. For more information, contact Wonderware Technical Support.

Configuring Remote Alarm Retrieval Queries When Running Windows Vista, Windows 7, or Windows Server 2008 R2

The process to configure remote alarm retrieval queries has changed for interactive applications such as InTouch HMI when running on Windows Vista, Windows 7, and Windows Server 2008 R2.

When InTouch WindowViewer is started and generates alarms from an interactive Windows Vista, Windows 7, or Windows Server 2008 R2 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.

To configure the AlarmViewer's alarm query

  1. After starting InTouch WindowViewer (alarm provider) on the Windows Vista, Windows 7, and Windows Server 2008 R2 node, open the SMC 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.
  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 "nodeabc" below and substituting your IP address noted in the previous step:

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.

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

Wonderware InTouch HMI and Alarm DB Logger

In earlier releases that supported Windows Vista, Windows 7, or Windows Server 2008, the Alarm DB Logger could not be enabled to run as a service. The Alarm DB Logger now runs as a Service in Windows Vista and later operating systems primarily to support Galaxy Alarms and InTouch HMI Alarms from Terminal sessions. However, there is a limitation in that the combination of Alarm DB Logger configured as a service and InTouch HMI running locally as a console application is still not supported. If InTouch HMI needs to run in the Console session, the Alarm DB Logger must be configured in the Alarm DB Logger Manager as a "Normal Application" instead of a "Windows Service".

Also, if you are running the Alarm DB Logger as a console application, you cannot run it in the Terminal session until you close the one that is running in as a console application.

Refer to the updated Tech Note 725, "Running InTouch HMI and AlarmDBLogger Services on Vista and Later Operating Systems," for full details of the supported scenarios and applicable alarm query syntax.

Terminal Services Behavior in Windows Server 2008 and Later Operating Systems

In a change from Windows Server 2003, Windows Server 2008 and later operating systems 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 and later operating systems, Session 0 is no longer an interactive session, and is reserved only for Windows services. Windows Server 2008 and later operating systems treat all remote connections 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 Terminal Server Console session. Refer to the Wonderware InTouch HMI 2012 R2 (v10.6) Readme for further information about InTouch HMI applications running in the Terminal Server Console.

 

In another aspect of Terminal Services behavior, InTouch HMI functions such as TSEGetClientID() can return a null value when running on Windows 2008 SP2 and Windows 2008 R2 operating systems 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 Terminal Server. You must install the "Terminal Server" role for Windows 2008 SP2 or the "Remote Desktop Host" role for Windows 2008 R2 in order for TSEGetClientId() and other related functions to work properly.

 

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

 

Wonderware Application Server and InTouch HMI detect when the application is running in the console. In Windows Server 2008 R2 it implies that the application was started by a user physically at the machine. However, this behavior requires that you disable Fast User Switching in both Windows 7 and Windows Server 2008 and later operating systems.

 

When running Windows Server 2008 and later operating systems, you must modify the terminal services behavior for the Wonderware software to operate properly.

 

Wonderware software detects when an application is running in the console. Windows Server 2008 and later operating systems treat all remote connections as a remote RDP session regardless of /consoleor /admin switches in the mstsc connection.

 

To disable fast user switching through the Group Policy interface

  1. Click Start and then Run. The Run dialog box appears.
  2. Enter gpedit.msc and click OK. The Group Policy dialog box appears.
  3. Go to the following location: Local Computer Policy > Administrative Templates > System > Logon.
  4. 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.
  5. 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.

Certain editions of Windows Vista do not have the Group Policy editor. So, alternatively, you can configure the Switch User settings through the registry.

To disable fast user switching through the Registry Editor

  1. Click Start and then Run. The Run dialog box appears.
  2. Enter regedit.exe and click OK. The Registry Editor dialog box appears.
  3. Go to the following location: HKEY_LOCAL_MACHINE > SOFTWARE > Policies > Microsoft > Windows > CurrentVersion > Policies > System.
  4. Right-click and select DWORD (32-bit) Value. Name it HideFastUserSwitching.
  5. Set the HideFastUserSwitching data value to 1.
  6. On the File menu, click Exit to close the Registry Editor.

In a Terminal Server environment that has a managed application deployed to it, the following behavior applies to references in the InTouch HMI application to the InTouchViewApp object:

ArchestrA Symbols referencing InTouchViewApp_001.Tag1:

Running on the Console - Refers to the tag value of the application running on the console.

Running in a Session - Refers to the tag value of the application running on the console.

Restarting the Window Viewer application running on the console causes references from the terminal session to disconnect and then reconnect.

InTouch Graphic referencing Tag1:

Running on the Console - Refers to the tag value of the application running on the console.

Running in a Session - Refers to the tag value of the application running in the session.

ArchestrA Graphic referencing InTouch:Tag1:

Running on the Console - Refers to the tag value of the application running on the console.

Running in a Session - Refers to the tag value of the application running in the session.

InTouch Graphic referencing Galaxy:InTouchViewApp_001.Tag1:

Running on the Console - Refers to the tag value of the application running on the console.

Running in a Session - Refers to the tag value of the application running on the console.

Operating System Notes: Wonderware InTouch HMI 2012 R2 (v10.6)

Following are notes specific to the InTouch HMI 2012 R2 (v10.6) operating system support and requirements.

  • The recommended operating system for a Galaxy Repository is Windows Server 2008 R2 SP1.
  • Microsoft Windows 7 (32-bit or 64-bit) is the recommended operating system to run InTouch HMI client components.
  • Microsoft Windows Server 2008 R2 is the recommended operating system to run InTouch HMI server components.
  • The recommended operating system for InTouch HMI development is Windows Server 2008 R2 SP1 or Windows 7 SP1.
  • The recommended operating system for run-time nodes is Windows 7 SP1.

Wonderware InTouch HMI 2012 R2 (v10.6) with Windows Vista, Windows 7, and Windows Server 2008 R2

  • Windows Vista does not support a dedicated single-node server configuration that runs one or more databases for an InTouch HMI system. 
  • If a computer runs Windows Vista as part of an InTouch HMI system, it cannot be configured to be both an InTouch HMI and ArchestrA alarm provider. The computer running Windows Vista can be either an InTouch HMI or an ArchestrA alarm provider, but not both simultaneously.
  • Wonderware InTouch HMI 10.6 does not support the following functions on these operating systems: WWPoke(), WWExecute(), WWRequest(), ActivateApp() and SendKeys().
  • If Recipe Manager is started using the path Start\Program\Wonderware\InTouch\Recipe, then select Run as Administrator on Windows Vista or later operating systems.
  • The InTouch Extensibility Toolkit might need to be started by right-clicking and selecting Run As Administrator on Windows Vista or later operating systems to function properly.
  • The onscreen keyboard options have changed for the Windows 7 and Windows Server 2008 R2 operating systems.
  • Hovering to select from the Windows keyboard does not work in the Windows 7 Professional and Windows Server 2008 R2 Standard operating systems.

Wonderware InTouch HMI 2012 R2 (v10.6) View Applications and DDE Support

Windows Vista and Windows Server 2008 do not support NetDDE 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. ArchestrA Symbols 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, ArchestrA Symbols cannot communicate with InTouch tags when used with an InTouchView license.

Windows Server 2003 and Windows XP Pro still support NetDDE.

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

Wonderware InTouch HMI 2012 R2 (v10.6) Support for Windows User Account Control

ArchestrA System Platform 2012 R2 with InTouch HMI v10.6 supports User Account Control-enabled operations on run-time nodes. You must disable User Account Control (UAC) before installing ArchestrA System Platform 2012 R2 and before performing Configurator operations. UAC also must be disabled on IDE and GR nodes.

Operating System Notes: Wonderware Application Server

  • Windows Server 2008 R2 SP1 is the recommended operating system for the Galaxy Repository node.
  • Windows 7 SP1 is the recommended operating system for Wonderware Application Server development (IDE) or run-time nodes (Bootstrap).
  • The Bootstrap, IDE, and Galaxy Repository are supported by the following language versions of Microsoft operating systems: English, Japanese, Simplified Chinese, German, and French. The Galaxy Repository is also supported by the English, Japanese, Simplified Chinese, German, and French versions of Microsoft SQL Server 2008 SP3, SQL Server 2008 R2 SP1, and SQL Server 2012.

Wonderware Application Server and DDE Support

In Windows Vista, Windows Server 2008, and later operating systems, DDE is supported only on a local node. Windows Vista, Windows Server 2008, and later operating systems do not support NetDDE. ArchestrA Symbols use the client layer when accessing InTouch tags and appear as a third-party client trying to access WindowViewer as a data server. Therefore the use of NetDDE for communication is not supported and not recommended.

In ArchestrA Symbols, InTouch:<tagname> is still a valid method of referring to an InTouch tag on a local node.

Using Wonderware Application Server with Windows 7 and Windows Server 2008 R2

This section describes specific behaviors and restrictions when using the Windows 7 and Windows Server 2008 R2 operating systems with Wonderware Application Server.

  • The DDESuiteLink Client connection to the local DAServer using DDE does not work with User Account Control enabled. The connection will work when User Account Control is disabled.
  • For toolkits such as the ArchestrA Object Toolkit, GRAccess Toolkit, and MXAccess Toolkit to function properly on Windows 7 and later operating systems, you may need to start the toolkit by right-clicking on the file and then clicking Run As Administrator.
  • Wonderware Application Server may experience performance degradation depending on how certain operating system tuning parameters are configured. For more information, see Tech Note 719, "Optimizing Wonderware Application Server Performance on Windows 7/Server 2008 R2", available for download from Wonderware Developers Network (WDN) Technical Support.

Wonderware Application Server and User Account Control Level

Application Server versions 3.1, 3.1 SP1, 3.1 SP2, 3.1 SP2 Patch 01, 3.1 SP3, 3.2, 3.5, and 3.6 support User Account Control-enabled run-time operations without elevated privileges.

On computers where the IDE or the GR is installed, User Account Control must be disabled. For more information about User Account Control support, see Wonderware InTouch HMI 2012 R2 (v10.6) Support for Windows User Account Control.

Operating System Notes: Wonderware Historian Server

Scenarios involving remote node communication fail if the Historian node is using the Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 operating system.

For example:

    1. When you log in as a local administrator on a computer and try to add a remote Wonderware Historian node (a second node with the Wonderware Historian installed) using the network account from the Management Console, the status of the remote Historian node is not reflected correctly.
    2. Test the connection from a Historian node using the operating system to a remote tier-2 historian. The following error message is shown: "Test Connection to replication server () failed: cannot connect to Tier-1 replication service (error 0x80004005: Unspecified error)"
    3. Replication to the remote tier-2 historian fails.
    4. Although a remote IDAS service starts successfully, errors and warnings stating "Failed to get IDAS configuration version..." and "Unable to start data acquisition" are logged. This problem occurs if the ArchestrA user account is a local user. If the ArchestrA user account is a domain user, then this problem does not occur.

Workaround:

    1. Open a command prompt and run the following command: cmd /c reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
    2. This sets LocalAccountTokenFilterPolicy registry entry value to 1. In doing so, an elevated token for the user is generated.
    3. Restart the system.

Operating System Notes: Wonderware Historian Client

When the Wonderware Historian Client application is running on Microsoft Windows Vista, Windows Server 2008, and Windows 7 operating systems, User Account Control can be enabled and running as non-administrator.

Operating System Notes: Wonderware Information Server

The MultiViews feature is not supported on the 64-bit versions of Windows 7 or Windows Server 2008 R2 SP1.

.NET Framework Requirements and Compatibility

 

IMPORTANT: We strongly recommended that prior to upgrading your existing applications to ArchestrA System Platform 2012 R2, that you back up your applications, become familiar with the changes introduced by Microsoft in .NET 4.0, and that you review your .NET scripts and .NET controls for any required changes. After upgrading to ArchestrA System Platform 2012 R2, 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.0. We also recommend you test the upgrade in a staging system prior to upgrading your production system.  

ArchestrA System Platform 2012 R2 leverages Microsoft .NET Framework 4.0. The ArchestrA System Platform installation program will install .NET 4.0 if it is not already present in your system. .NET 4.0 can coexist with previous versions of .NET Framework. On nodes where SQL Server is installed, .NET 3.5 is also installed by ArchestrA System Platform. In this scenario, ArchestrA System Platform 2012 R2 will use .NET 4.0. Other applications you may have on the same machine with dependencies on .NET 3.5 will access .NET 3.5.  

All user-supplied .NET code that runs in the context of InTouch HMI and Application Server will now run under the .NET Framework 4.0. Although .NET Framework 4.0 is highly compatible with applications that are built with earlier .NET Framework versions, Microsoft has introduced changes in .NET 4 to improve security, standards compliance, correctness, reliability, and performance that may require changes to .NET scripts you may have created with ArchestrA System Platform 2012 and earlier versions of Application Server, InTouch HMI, the Historian, Historian Client, and Wonderware Information Server. These changes may also affect .NET controls developed with .NET 3.5.

In ArchestrA 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.0. To enable an ArchestrA 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 .NET Framework 4.0 see the following Microsoft resources:

What's New in the .NET Framework 4: http://msdn.microsoft.com/en-us/library/ms171868%28VS.100%29.aspx
What's obsolete in the .NET Framework class library: http://msdn.microsoft.com/en-us/library/ee461502.aspx
Migration Guide to the .NET Framework 4: http://msdn.microsoft.com/en-us/library/ff657133%28v=vs.100%29
.NET Framework 4 Migration Issues: http://msdn.microsoft.com/en-us/library/ee941656%28v=vs.100%29

Virtualization Support

ArchestrA System Platform 2012 R2 supports the following virtualization environments:

  • Microsoft Hyper-V: based on the supported operating system version
  • VMware 5.0: basic virtualization without High Availability and Disaster Recovery
  • VMware VSphere 5

SQL Server Requirements

SQL Server Requirements for All Wonderware Components

The following table details the SQL Server requirements for ArchestrA System Platform 2012 R2 components. The recommended environment is a 64-bit operating system and SQL Server 2008 R2 SP1, Standard, Enterprise, 32/64-bit. For more information, see SQL Server Installation Notes.

  2008 SP3 Express-SSMSE (32-bit) 2008 SP3 Standard, Enterprise (32-bit Only) 2008 R2 SP1 Express-SSMSE (32-bit) 2008 R2 SP1 Standard, Enterprise (32/64 bit) 2012 Express-SSMSE (32-bit) 2012 Standard, Enterprise (32/64 bit)
InTouch 2012 R2 (v 10.6)

 

S Y S Y S Y
Application Server 2012 R2 (v3.6) S Y S Y S Y
Historian 2012 R2 (v11.0) S Y S Y S Y
Historian Client 2012 R2 (v10.1)            
Information Server Portal 2012 R2 (v5.0) S Y S Y S Y
Information Server Clients 2012 R2 (v5.0)            
             
Compact Installation (1-500 I/O per node) Y N Y N Y N
Small Installation (1-5,000 I/O per node) N Y N R N Y
Medium Installation (5k-50k I/O per node) N Y N R N Y
Large Installation (50k-400k I/O per node) N N N R N Y

 

Supported Y
Small System Only S
Supported and Recommended R
Not Supported N
Not Applicable  

 

SQL Server Notes: Common for All Wonderware Products

SQL Server Rights Requirements

SQL Server 2008 does not automatically create the BUILTIN\Administrators role delivered in SQL Server 2005. Because of this change to SQL Server, the Wonderware Application Server 2012 R2 (v3.6) installation process will create the necessary operating system user group (aaAdministrators) as well as the necessary SQL Server role. This automated process will provide the rights required to allow operations within the Galaxy Repository without the need for blanket BUILTIN\Administrator rights. The aaAdministrators group must be present and enabled. If you accidentally delete the aaAdministrators group from the Windows operating system, you can run either of two options to restore it:

  • Run the Change Network Utility from the Windows Start menu.
  • Run the aaConfig SQL Utility from the Windows Start menu.

If you accidentally delete the aaAdministrators group from the SQL Server security logins, you must run the aaConfig SQL Utility to restore it. Refer to the Wonderware Application Server User's Guide, About ArchestrA User Accounts, for further information and procedures about restoring the aaAdministrators group.

SQL Server Notes: Wonderware Application Server

  • If multiple versions of SQL Server are installed, the one utilized as the Galaxy Repository must be the default instance.
  • The Galaxy Repository locks the SQL Server maximum memory usage to 65% of the computer's physical memory.
  • TCP/IP must be enabled on the computer hosting a SQL Server 2008 database. The TCP/IP protocol setting can be verified from the SQL Server Network Configuration under SQL Server Configuration Manager.
  • To use the Alarm DB Logger with SQL Server Express, you need to change the default authentication mode from Windows-based to Mixed Mode.
  • When upgrading SQL Server on the Galaxy Repository node, back up the Galaxy before starting the upgrade. Upload any run-time changes for critical objects. You cannot upload any run-time changes after you upgrade the system. For more information, see the Wonderware Application Server upgrade notes. Also see the Wonderware Application Server Installation online Help.

SQL Server Notes: Wonderware Information Server

In addition to the SQL Server requirements specified in Summary of Requirements for ArchestrA System Platform 2012 R2, note the following SQL Server considerations for the Wonderware Information Server:

  • Named instances are not supported.
  • Wonderware Information Server supports case-insensitive and case-sensitive SQL Servers.

SQL Server Notes: Wonderware Historian Server

In addition to the SQL Server requirements specified in Summary of Requirements for ArchestrA System Platform 2012 R2, note the following SQL Server considerations for the Wonderware Historian Server:

  • The MSSQL Server user account is not supported for the SQL Server 2012 Service. Instead, configure SQL Server to run as the local system or Network Service account.