InTouch Hardware Requirements

• The recommended operating system for InTouch development is Windows 2008 R2 SP1 or Windows 7 SP1.
• The recommended operating system for run-time nodes is Windows 7 SP1.
• SQL Server 2008 SP1 Express, Standard, or Enterprise (32-bit) is the only supported version at this time.

Auxiliary Hardware Requirements

Using Wonderware InTouch with Windows 7 Embedded

Windows 7 Embedded has been qualified and supported for InTouch run time (WindowViewer) and FS Gateway. It is not supported for use in a development environment (IDE), for local process and alarm storage, or for historical logging.

Windows 7 Embedded is identical to the desktop version of Windows 7 operating system, but has specific hardware requirements that are listed in the Hardware Requirements section. It also has the following licensing restrictions:

• Hide the Shell functionality requires the use of a custom shell in place of the Windows shell for the device. Embedded devices should boot directly into the embedded applications, such as InTouch.
• Single application purpose: An embedded device must be a dedicated single-purpose device, such as an Industrial HMI Operator Station.

Using Wonderware InTouch 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 system, it cannot be configured to be both an InTouch and ArchestrA alarm provider. The computer running Windows Vista can be either an InTouch or an ArchestrA alarm provider, but not both simultaneously.
• InTouch HMI version 10 or later can run under Windows Vista Enterprise, Windows Vista Business, or Windows Vista Ultimate. The Windows Vista Home Basic and Home Premium editions are not supported.
• For Windows Vista, you can run InTouch HMI only on the 32-bit version.
• The Alarm DB Logger can be configured to run as a service in Windows Vista or later operating systems, including Windows Server 2008, Windows Server 2008 R2, and Windows 7 operating systems. However, the InTouch HMI cannot be configured to run as a service in these operating system. You cannot configure the InTouch HMI to run as a service as a way to automatically start it. For instructions on an alternate technique for automatically starting the InTouch HMI process, see Tech Note 725, available from the Wonderware website.
• Wonderware InTouch 10.5 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 may 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.

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 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.

Support for Windows Operating System User Account Control

InTouch version 10.5 supports User Account Control-enabled run-time operations without elevated privileges. For all configuration and installation operations, including those called during run-time operations, User Account Control must be disabled or privileges must be elevated to the required level.

Remote Alarm Retrieval Queries

The process to configure remote alarm retrieval queries has changed for interactive applications such as InTouch when running on operating systems such as Windows 7 and Windows Server 2008 R2. When InTouch WindowViewer is started and generates alarms from interactive Windows 7, Windows Server 2008 R2, or Windows Vista desktop session, an AlarmViewer control (running within InTouch) 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 as an alarm provider running in a Terminal Services session, not for InTouch running in a console session.

To configure the AlarmViewer's alarm query

1. After starting InTouch WindowViewer (alarm provider) on the Windows 7, Windows Server 2008 R2, or Windows Vista 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 for "nodeabc" below and substituting your IP address noted in the previous step: \\nodeabc:253.127.148.120\intouch!$system.
3. Test to validate that the alarms generated from the alarm-providing node are shown accurately in the AlarmViewer control.

Terminal Services Behavior

Modify terminal services behavior in Windows Server 2008 for proper operation of the software. Wonderware software detects when an application is running in the console. Windows Server 2008 treats all remote connections as a remote RDP session regardless of /console or /admin switches in the mstsc connection.

To disable the ability to switch users through the Group Policy interface

1. Click Start. The Start menu appears.
2. Select Run. The Run dialog box appears.
3. In the Run dialog box, enter gpedit.msc. 
4. Click OK. The Group Policy dialog box appears.
5. Go to the following location: Local Computer Policy > Administrative Templates > System > Logon.
6. 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.
7. On the File menu, click Exit to close the Group Policy editor.

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

To disable the ability to switch users through the Registry Editor

1. Click Start. The Start menu appears.
2. Click Run. The Run dialog box appears.
3. In the Run dialog box, enter regedit.exe.
4. Click OK. The Registry Editor dialog box appears.
5. Go to the following location: HKEY_LOCAL_MACHINE > SOFTWARE > Policies > Microsoft > Windows > CurrentVersion > Policies > System.
6. Right-click and select DWORD (32-bit) Value. Name it HideFastUserSwitching.
7. Set the HideFastUserSwitching data value to 1.
8. 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 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. 

Using Multiple Network Interface Cards

If you are using multiple network interface cards (NICs), you must configure certain settings for the firewall or else a remote node cannot connect to the Galaxy Repository node.

A connection is a term used to define a network interface card (NIC), its settings and the settings of whatever the NIC is connected to. Under certain circumstances, the connection on your computer can change if, for example, the IP address on your network card changes. Your computer's connection can be affected by external factors. During computer startup, and each time a connection changes, the operating system goes through an "Identifying" process to determine which profile should be assigned to the connection.

A profile is a collection of firewall settings that can be applied to a connection. There are three profiles currently defined in the operating system: Domain, Public, and Private.

• The Domain profile is active only when the computer can authenticate with a domain controller on all active interfaces such as LAN, wireless, and VPN. The domain profile may be more or less restrictive than the other two profiles depending on network security policies.  
• The Private profile is active whenever the network type for all active network connections on the computer are identified as private networks. The private profile typically is used in a more trusted environment and is less restrictive than the public profile to allow for network discovery.
• The Public profile is active in all other circumstances. The public profile typically is more restrictive than the private profile because the computer often is connected to the Internet in an insecure location. Network discovery and remote access are disabled rather than explicitly blocking specific traffic. Firewall exceptions and rules can be created on any or all of these profiles.

This is important because the OS Configuration utility and the Firewall utility apply their firewall exceptions to the Domain and Private profiles only. 

As previously noted, you can specify which profile you want assigned to a connection as long as that connection is not a Domain connection. This is done through the "Network and Sharing Center". Click the Network icon located on the right side of the task bar and then click one of the networks that are shown. You can change a connection from a Public profile to a Private profile. The firewall calls these settings "Profiles" but the network calls them "Location types." 

On computers using dual NICs, the first NIC is normally connected to the domain and is assigned the Domain profile automatically. Windows typically assigns the second NIC the Public profile. 

The first issue is that your entire computer (all connections) is restricted to the most restrictive of the profiles assigned to any connection. So if the second connection was assigned a profile of Public, none of the firewall exceptions set by the OS Configuration or Firewall utilities will be allowed. The exceptions were set for Domain and Private only, not Public. You must set the second connection to the Private profile for any of the  firewall exceptions to work. You want the active profile on the message exchange (MX) NIC to be the profile opened by OS Configuration.

The second issue is that it appears that a restart of your computer, or even a restart of a computer to which you are connected, can change your connection back to the Public profile. Once again the firewall exceptions will not be effective. You'll have to change the connection back to the Private profile after each restart or a restart of the connected computer.

To avoid these NIC issues and prevent the “Identifying” process from taking place on a connection and changing the assigned profile, certain items must be present in the definition of the connection. Follow these rules and procedures:

• If you have only one NIC, no action is required. The profiles and firewall rules are automatic.
• To configure two NICs, do the following:

1. If the second NIC is not physically connected to anything (that means no wire in it), no action is required. The profiles and firewall rules are automatic.
2. If the second NIC is connected, it MUST be configured. Follow the rules for configuring a normal redundancy setup provided in the Wonderware Application Server User's Guide and the accompanying online help.

• ​​Assign the NIC an IP address, subnet mask and gateway address. Typically, these addresses are internal, non-routable addresses. For example, 192.168.1.xx and 10.x.x.x are common addresses of this type.
• A NIC acting as Redundancy Message Channel (RMC) does not require a default gateway.     Otherwise, the gateway can be the same as the IP address. Vista and Windows Server 2008 will identify this NIC and assign it a Private profile.

       If you do not configure the second NIC, Vista and Windows Server 2008 will assign a profile of Public to this         NIC and cause all of the Wonderware product firewall exceptions to be deactivated on all NICs.

3. Set a security policy so that Windows Vista and Windows Server 2008 do not re-set the RMC NIC to a Public profile on rebooting the system or changing the IP address. To make the Private profile setting persistent, do the follwing:

• On the Windows Start menu, click Run.
• Enter and run this command: SECPOL.MSC. The Local Security Settings menu appears.
• Select Network List Manager Policies on the menu tree.
• Select Unidentified Network from the Network Names displayed.
• Right-click, then select Properties, and then change the Location type from Not configured to Private.
• Exit the menu and return to Windows.

4. If you have more than two NICs, make sure all connected NICs are configured with an IP address.

Installing the Wonderware InTouch HMI

The simplified process makes installing InTouch easier than ever.
The major decision you must make when you install InTouch HMI is whether to install the InTouch development and run-time components, or the run-time components alone.
The installation program guides you in selecting the features you want, verifying or modifying your selections, installing prerequisite software, and then installing InTouch HMI and the ArchestrA IDE if you chose to install development components.

Detailed Steps

Licensing

 Please click HERE for details on licensing.

Validation of Solution

Text...

Related Videos