225 Deployment Guide 225

InTouch_TSE_DG_1.0.docx Rev. 1.0 Client Page 1 of

139

InTouch for Terminal Services Deployment Guide Planning and Implementation Guidelines Revision: 1.0

© Copyright 2013, Invensys Systems Inc.

InTouch for Terminal Services Deployment Guide

Rev. 1.0 Client Page 2 of

139

© 2013 Invensys Systems, Inc. All rights reserved.

No part of the material protected by this copyright may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying, recording, broadcasting, or by any information storage and retrieval system, without permission in writing from Invensys Systems, Inc.

Invensys, Wonderware, ArchestrA, InTouch, ActiveFactory, InControl, and Factelligence are trademarks and registered trademarks of Invensys plc, its subsidiaries and affiliated companies. All other brands and product names may be the trademarks or service marks of their respective owners. Wonderware, a business unit of Invensys 26561 Rancho Parkway South Lake Forest, CA 92630 www.wonderware.com

http://www.wonderware.com/



139

Table of Contents

ACKNOWLEDGEMENTS ............................................................................................................................ 6

AUTHORING AND TESTING: ................................................................................................................................ 6 REVIEW AND DISTRIBUTION .............................................................................................................................. 6

WELCOME TO INTOUCH FOR TERMINAL SERVICES ................................................................................... 7

TERMINOLOGY ................................................................................................................................................ 7 ASSUMPTIONS ................................................................................................................................................ 8 TECHNICAL SUPPORT ....................................................................................................................................... 8

USING TERMINAL SERVICES ..................................................................................................................... 9

RUNNING A MANAGED INTOUCH APPLICATION WITH TERMINAL SERVICES ............................................................... 10 Key Points ............................................................................................................................................. 10

DEPLOYING THE INTOUCHVIEWAPP OBJECT IN A TERMINAL SERVICES ENVIRONMENT ................................................ 12 CONFIGURE HISTORICAL LOGGING ON INTOUCH FOR TERMINAL SERVICES ................................................................ 13 CONFIGURING AUTOMATIC STARTUP ................................................................................................................ 14 MISCELLANEOUS LIMITATIONS IN A TERMINAL SERVICES ENVIRONMENT .................................................................. 15

INTRODUCTION TO INTOUCH FOR TERMINAL SERVICES ........................................................................ 16

INTOUCH FOR TERMINAL SERVICES ................................................................................................................... 16 INTOUCH IN THE TERMINAL SERVICES ENVIRONMENT .......................................................................................... 16

Why was Terminal Services renamed to “Remote Desktop Services” In Windows Server 2008 R2? ... 17 How the /admin switch behaves .......................................................................................................... 17 Remote Desktop Services (Role) ........................................................................................................... 19 Using Remote Desktop Services ........................................................................................................... 20 Remote Desktop Services (Role services) ............................................................................................. 21

INSTALLING REMOTE DESKTOP SERVICES ........................................................................................................... 23 Install Remote Desktop Services (Role) ................................................................................................ 23 Install Specific Remote Desktop Services ............................................................................................. 25

INTOUCH FOR TERMINAL SERVICES ................................................................................................................... 28 Why InTouch for Terminal Services? .................................................................................................... 28 Terminal Services Benefits for InTouch ................................................................................................ 28 Remote Control .................................................................................................................................... 33

GETTING STARTED WITH INTOUCH FOR TERMINAL SERVICES ................................................................ 34

UNDERSTANDING INTOUCH FOR TERMINAL SERVICES ........................................................................................... 34 Key Points ............................................................................................................................................. 34

RUNNING INTOUCH APPLICATIONS IN A TERMINAL SERVICES ENVIRONMENT ............................................................ 35 Standalone InTouch for Terminal Services configuration created using Wonderware WindowMaker. ............................................................................................................................................................. 35 Running a Managed InTouch Application with Terminal Services ....................................................... 35 Running a Published InTouch Application with Terminal Services ....................................................... 37

TYPES OF INTOUCH FOR TERMINAL SERVICES ...................................................................................................... 37 WINDOWS 2008/R2 .................................................................................................................................... 38 TERMINAL SERVICES BEHAVIOR IN WINDOWS SERVER 2008 ................................................................................. 38 ACP THIN MANAGER .................................................................................................................................... 39

How ThinManager Works .................................................................................................................... 40

PLANNING CONSIDERATIONS FOR TERMINAL SERVER APPLICATIONS ................................................... 41



139

SYSTEM REQUIREMENTS ................................................................................................................................. 41 WORKING WITH NETWORK LOAD BALANCING .................................................................................................... 43

About the Network Load Balancing Feature ........................................................................................ 43 About Remote Desktop Connection Broker .......................................................................................... 43 About Managed InTouch Applications with Network Load Balancing................................................. 44

SETTING UP A NETWORK LOAD BALANCING CLUSTER ........................................................................................... 46 Topology 1: Leveraging Network Load Balancing by Configuring Remote Desktop Connection Broker on One of the NLB Cluster Nodes ......................................................................................................... 47 Topology 2: Leveraging Network Load Balancing by Configuring Remote Desktop Connection Broker on a Separate Node ............................................................................................................................. 49

INSTALLING REMOTE DESKTOP SERVICES ........................................................................................................... 51 Installing Network Load Balancing ...................................................................................................... 57 Adding a Remote Desktop Session Host Server .................................................................................... 59 Creating a Network Load Balancing Cluster ........................................................................................ 61

CONFIGURING REMOTE DESKTOP CONNECTION BROKER SETTINGS ......................................................................... 69 DISCONNECTING FROM AND CONNECTING TO A REMOTE DESKTOP SESSION ............................................................ 73

Viewing Connected Sessions ................................................................................................................ 73

WONDERWARE LICENSING .................................................................................................................... 76

LICENSE TYPES .............................................................................................................................................. 76 HOW WONDERWARE SOFTWARE USES LICENSES ................................................................................................ 77

Wonderware CAL (Client Access License) ............................................................................................. 78 When You Need a CAL.......................................................................................................................... 78 InTouch Runtime TSE License file ......................................................................................................... 78 Installing the InTouch for Terminal Services License ............................................................................ 81 Remote Desktop Licensing ................................................................................................................... 82

PLANNING SECURITY IN A TERMINAL SERVICES ENVIRONMENT ............................................................ 83

DEFINING SECURITY ....................................................................................................................................... 83 Physical Security................................................................................................................................... 83 Application Security ............................................................................................................................. 84 Session Security .................................................................................................................................... 84 Assign Group Privileges ........................................................................................................................ 88 User Account Management ................................................................................................................. 88 Securing the RDP connection ............................................................................................................... 91 Security Layer ....................................................................................................................................... 91

ENCRYPTION LEVEL ........................................................................................................................................ 92 NETWORK LEVEL AUTHENTICATION .................................................................................................................. 93

Disable the ability to switch users through the Group Policy interface ............................................... 93 NEW WINDOWS SERVER 2008 R2 SECURITY FEATURES ....................................................................................... 95

AppLocker ............................................................................................................................................ 96 New features in User Account Control ................................................................................................. 97 New Features in Windows Security Auditing ....................................................................................... 97 Using Auditing...................................................................................................................................... 98

I/O IN A TERMINAL SERVICES ENVIRONMENT ........................................................................................ 99

INTRODUCTION ............................................................................................................................................. 99 I/O SERVERS IN A TSE ENVIRONMENT ............................................................................................................. 100 WHAT HAPPENS WHEN WINDOWVIEWER OPENS .............................................................................................. 100 I/O SERVERS ON A SEPARATE NODE ................................................................................................................. 101 EXECUTING SCRIPTS IN A TERMINAL SERVICES ENVIRONMENT .............................................................................. 101 CREATING A TAG SERVER APPLICATION ........................................................................................................... 104



139

ALARMS IN A TERMINAL SERVICES ENVIRONMENT ............................................................................. 106

APPENDIX 1: RETRIEVING INFORMATION ABOUT THE INTOUCH CLIENT SESSION USING SCRIPTS ....... 108

APPENDIX 2: TECH NOTE 538 INTOUCH© TSE VERSION 10.0 APPLICATION CONFIGURATION: MANAGED, PUBLISHED AND STANDALONE METHODS ........................................................................................... 110

INTRODUCTION ........................................................................................................................................... 110 Application Version ............................................................................................................................ 110

MANAGED APPLICATIONS ............................................................................................................................. 110 Creating an InTouch for Terminal Services Managed Application Environment with Application Server 3.0 and InTouch 10.0 ......................................................................................................................... 111 Managed Applications File Locations ................................................................................................ 113 Managed Application: Edit File Locations .......................................................................................... 113

MANAGED APPLICATION: DEPLOYED FILE LOCATIONS ........................................................................................ 114 MANAGED APPLICATION: LOCAL WORKING DIRECTORY FILE LOCATIONS ............................................................... 116 MANAGED APPLICATION: FILE LOCATIONS WHEN EXECUTED FROM THE CONSOLE ................................................... 118 PUBLISHED APPLICATIONS ............................................................................................................................. 121 STANDALONE APPLICATIONS ......................................................................................................................... 123

APPENDIX 3: INTOUCH LICENSING ....................................................................................................... 124

USING THE LICENSE UTILITY .......................................................................................................................... 124 INTOUCH 2012 LICENSE FILE......................................................................................................................... 127 INSTALLING THE REMOTE DESKTOP SERVICES LICENSE SERVER ............................................................................. 128 ACTIVATE A LICENSE SERVER ......................................................................................................................... 130 ACTIVATING THE RD LICENSE SERVER .............................................................................................................. 131 INSTALLING LICENSES ................................................................................................................................... 132

Install Remote Desktop Services Client Access Licenses by Using a Web Browser ............................. 136 Install Remote Desktop Services Client Access Licenses by Using the Telephone .............................. 136

CLIENT LICENSING ....................................................................................................................................... 137 ADDITIONAL RESOURCES .............................................................................................................................. 138

SOURCES .............................................................................................................................................. 139



139

ACKNOWLEDGEMENTS

This Deployment Guide was authored, tested and reviewed by an I.O.M. Global Customer Support team, which includes the following people:

AUTHORING AND TESTING:

Alicia Rantos (GCS Lake Forest) Nagat Mahmoud (GCS Cairo) Mohamed Salah (GCS Cairo) Ragaei Mahmoud (GCS Cairo) Mohamed AbouELSoud (GCS Cairo) Amr Shebl (GCS Cairo)

REVIEW AND DISTRIBUTION

Ray Norman (Application Engineering Lake Forest) Marco Siscovich (GCS Italy) Denis Lebrun (Wonderware France) John Krajewski (Lake Forest) Rob Kambach (Lake Forest) Eduardo Ballina (Lake Forest) Michael Boor (GCS Lake Forest)



139

WELCOME TO INTOUCH FOR TERMINAL SERVICES

Before You Begin

The InTouch for Terminal Services Deployment Guide is intended to help you efficiently plan, deploy and run InTouch applications on Windows 2008 R2 Remote Desktop Services (formally Terminal Services).

As a complement to the InTouch for Terminal Services User’s Guide, it provides greater detail in architecture design, hardware selection, and how to leverage the features of Terminal Services in an industrial environment. It specifically addresses the RDP protocol. Additional information on RDP and related protocols are available at the following websites:

Microsoft Terminal Services Overview http://technet.microsoft.com/en-us/library/cc755053(WS.10).aspx

Remote Desktop Services Overview http://technet.microsoft.com/en-us/library/cc725560.aspx

Remote Desktop Services http://technet.microsoft.com/en-us/windowsserver/ee236407.aspx

Automation Control Products (ACP) http://www.acpthinclient.com

Note: Adding ACP ThinManager™ increases the available client types to non-Windows-based workstations, including UNIX, Linux, and industrial display panels. Consult your vendor to verify Wonderware support for a particular non-Windows-based operating system.

TERMINOLOGY

Console: This is the normal desktop experience on the computer that has Terminal Services installed.

RDP: Remote Desktop Protocol. The default connection protocol installed with Windows Terminal Services.

RDS: Remote Desktop Services

Session: A log-on instance where 100 percent of the resources (processing, memory, and hard disk) are managed under a virtual user account, referred to as a Session ID.

Terminal Services: A service that enables a server-grade computer for multi-user processing and management.

http://technet.microsoft.com/en-us/library/cc755053(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc755053(WS.10).aspx

http://technet.microsoft.com/en-us/library/cc725560.aspx

http://technet.microsoft.com/en-us/library/cc725560.aspx

http://technet.microsoft.com/en-us/windowsserver/ee236407.aspx

http://technet.microsoft.com/en-us/windowsserver/ee236407.aspx

http://www.acpthinclient.com/



139

Thin Client: (a.k.a. Terminal) A device that allows you to send commands to another computer. At a minimum, this usually means a keyboard, a display screen, and some simple circuitry.

ASSUMPTIONS

This manual assumes you are:

„ Familiar with the Windows 2008 R2 operating system working environment.

„ Knowledgeable of how to use of a mouse, Windows menus, select options, and accessing online Help.

„ Experienced with a programming or macro language. For best results, you should have an understanding of programming concepts such as variables, statements, functions and methods.

TECHNICAL SUPPORT

Wonderware Technical Support offers a variety of support options to answer any questions on Wonderware products and their implementation.

Prior to contacting technical support, please refer to the relevant chapter(s) in your InTouch for Terminal Services Deployment Guide for a possible solution to any problem you may have with your system. If you find it necessary to contact technical support for assistance, please have the following information available:

1. Your software serial number.

2. The version of InTouch you are running.

3. The type and version of the operating system you are using. For example, Microsoft Windows 2008 R2 SP1 (or later) workstation.

4. The exact wording of system error messages encountered.

5. Any relevant output listing from the Wonderware Logger, the Microsoft Diagnostic utility (MSD), or any other diagnostic applications.

6. Details of the attempts you made to solve the problem(s) and your results.

7. Details of how to recreate the problem.

8. If known, the Wonderware Technical Support case number assigned to your problem (if this is an on-going problem).



139

USING TERMINAL SERVICES

Terminal Services is a configurable service included in the Microsoft Windows Server operating systems that runs Windows-based applications centrally from a server. In Terminal Services, client computers access the server node, where multiple instances of InTouch software applications run simultaneously.

The Terminal Services environment has three main parts:

Terminal Services Server: The server manages the computing resources for each client session and provides client users with their own unique environment. The server receives and processes all keystrokes and mouse actions performed at the remote client, then directs all display output for both the operating system and applications to the appropriate client. All Terminal Services application processing occurs on the server.

Remote Desktop Protocol (RDP): A Remote Desktop Protocol (RDP) client application passes the input data, such as keystrokes and mouse movements, to the server.

Client: The Terminal Services client performs no local application processing; it just shows the application output. You access Terminal Services from a client by running the Terminal Services Client command on the Windows Program menu. When you connect to the Terminal server, the client environment looks the same as the Windows server. The fact that the application is not running locally is completely transparent.

For more information about Terminal Services, including features and benefits, see your Microsoft documentation.



139

RUNNING A MANAGED INTOUCH APPLICATION WITH TERMINAL SERVICES

You can run managed InTouch applications in a Terminal Services environment. The benefit of using Terminal Services is that it allows you to run multiple, autonomous InTouch applications simultaneously on a Terminal Server.

KEY POINTS

In a typical Terminal Services architecture, application development, deployment, and client visualization are placed on separate computers.

You must deploy each InTouch application to the server running InTouch for Terminal Services.

You run each managed InTouch application in a separate terminal-services client session.

For more information, see Chapter 4, Using IDE-Managed InTouch Applications at Run Time, in the InTouch® HMI and ArchestrA® Integration Guide.



139

The following graphic shows the Galaxy and InTouch Development Nodes in this context:



139

DEPLOYING THE INTOUCHVIEWAPP OBJECT IN A TERMINAL SERVICES

ENVIRONMENT

You can run managed InTouch applications in a Terminal Services environment. The main advantage of this architecture is that you can run multiple InTouch applications on one computer at the same time.

To do this, you must:

„ Install InTouch 10.x or later on a computer with Remote Desktop Services (RDS) installed.

„ Run each managed InTouch application on its own terminal Server Node.

„ Run each InTouch View client in a separate Terminal Services client session.

Note: Each Terminal Services client session uses a unique user logon.



139

CONFIGURE HISTORICAL LOGGING ON INTOUCH FOR TERMINAL SERVICES

We recommend using one historical logging file for all the clients.

Configure Historical Logging using the $HistoricalLogging tagname.

Create an Application Startup script using TSEQueryRunningOnClient().

Code Example (from above figure): Client = TseQueryRunningOnClient(); IF client == 1 THEN IOSAccessName["Tagserver","davidu6","View","Tagname"]; $HistoricalLogging = 0; ENDIF;



139

CONFIGURING AUTOMATIC STARTUP

Configure InTouch automatic startup from the Computer Management panel's User properties window (following figure) in the Environment tab. Set these options for each user.



139

MISCELLANEOUS LIMITATIONS IN A TERMINAL SERVICES ENVIRONMENT

The following table describes the limitations and suggested solutions to run applications on a terminal server.

Feature Supported? Comment

WindowViewer Yes WindowViewer is not supported running as a

service under Terminal Services.

DDE to an I/O Device or MS

Office (for example, Excel)

No Use a tag server (console or separate

computer). This includes DDE QuickScripts:

WWExecute(), WWPoke()

and WWRequest().

DDE from MS Office (for

example, Hot-link

configured in Excel)

Yes Excel and the InTouch HMI must be running in

the same session.

Historical Trending Yes Use a tag server or NAD to log values.

Multiple sessions may read the same historical

files, but only a console can write to historical

files.

InTouch Alarm DB Logger Yes --

MEM OLE Automation No --

Printing Alarms No --

Retentive tags Yes Must use NAD or Managed Application.

SPC Pro No Not supported

SQL Access (ODBC) Yes Database should be on a separate computer.

SuiteLink to an I/O Device

or another InTouch

application.

Yes When communicating to another view session,

include the Terminal Server node name and

append the IP address of the desired session to

the application name. For example,

view10.103.25.6.

I/O Servers are not supported in client sessions.

.



139

INTRODUCTION TO INTOUCH FOR TERMINAL SERVICES

This section provides an overview of InTouch for Terminal Services. It also presents business and industrial scenarios to help you determine if a server-centric strategy is appropriate for your particular application.

INTOUCH FOR TERMINAL SERVICES

InTouch for Terminal Services is a variation of the regular InTouch version and is intended for computers running server versions of Windows with Terminal Services enabled.

You can use InTouch for Terminal Services to run InTouch on one central server and supply InTouch functionality to multiple client computers without imposing any further software or hardware requirements on the client computers. In this environment, the hardware and software requirements for the server are relatively high and those for the clients relatively low.

INTOUCH IN THE TERMINAL SERVICES ENVIRONMENT

Terminal Services is a configurable service included in the Microsoft Windows Server operating systems that runs Windows-based applications centrally from a server. In Terminal Services, client computers access the server node, where multiple instances of InTouch software applications run simultaneously.

Internet

ModemRD Gateway

Internal RD Clients

External RD Clients

RD Services 2008 R2

Remote Desktop Services

(Terminal Services)

2008 R2 Environment

IO Server

RDP\ICA protocol is usedto view the InTouch session

InTouch Application

RD Terminal Server

2008 R2

PLCs



139

WHY WAS TERMINAL SERVICES RENAMED TO “REMOTE DESKTOP SERVICES” IN WINDOWS

SERVER 2008 R2?

In Windows Server 2008 and Windows Server 2008 R2, the /console switch functionality is no longer needed:

Improved application compatibility guarantees that legacy applications that have to communicate with services in session 0 are installed and are run in sessions other than session 0. Additionally, if the service that is associated with an application tries to display UI elements in session 0, a built-in capability in Windows Server 2008, Windows Server 2008 R2 and in Windows Vista enables you to view and to interact with the session 0 UI from your session. Windows Server 2008/Windows Server 2008 R2 session 0 is an interactive session that is reserved for services. Therefore, there is no need for you to explicitly connect to this session.

Because the physical console session is never session 0, you can always reconnect to your existing session on the physical console. The Restrict Terminal Services users to a single remote session Group Policy setting determines whether you can connect to your existing physical console session. This setting is available in the Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections node of the Local Group Policy Editor. You can also configure this setting in Terminal Services Configuration. The Restrict each user to a single session setting appears in Edit settings in the General section.

HOW THE /ADMIN SWITCH BEHAVES

You can run the RDC 6.1 client (Mstsc.exe) together with the /admin switch to remotely administer a Windows Server 2008-based server that has or does not have Terminal Server installed. However, if you are trying to remotely administer a Windows Server 2008-based server that does not have the Terminal Server role service installed, you do not have to use the /admin switch. In this case, the same connection behavior occurs with or without the /admin switch.

Two active remote administration sessions can run at any point in time.

To start a remote administration session, you must be a member of the Administrators group on the server to which you are connecting.

The following graphic shows that in Windows XP, Windows Server 2003, and earlier versions of the Windows operating system. All services run in the same session as the first user who logs on to the console. This session is called Session 0. Running services and user applications together in Session 0 is a security risk because services run at elevated privilege and therefore are targets for malicious agents who are looking for a way to elevate their own privilege level.



139

Session 0

Application 1

Application 2

Application 3

Service 1

Service 2

Service 3

Session 1

Application 4

Application 5 Application 6

Application 7


Session 2

With Windows Vista, Windows Server 2008, and later versions of Windows, sessions are assigned as shown in the following figure.



139

Session 0

Service 1 Service 2

Service 3

Session 1

Application 1


Application 4


Session 2

Application 7


Session 3

In this graphic, three users are logged on to the system. However, only services run in Session 0. The first user logs on to Session 1, and Sessions 2 and 3 represent subsequent users.

REMOTE DESKTOP SERVICES (ROLE)

Remote Desktop Services (formerly Terminal Services), is a server role in Windows Server® 2008 R2. This role provides technologies that enable users to access Windows-based programs installed on a Remote Desktop Session Host (RD Session Host) server, or to access the full Windows desktop.



139

USING REMOTE DESKTOP SERVICES

You can access an RD Session Host server from within a corporate network or from the Internet.

Remote Desktop Services lets you efficiently deploy and maintain software in an enterprise environment.

You can easily deploy programs from a central location.

Because you install the programs on the RD Session Host server and not on the client computer, programs are easier to upgrade and to maintain.

When a user accesses a program on an RD Session Host server, the program runs on the server. Each user sees only their individual session. The session is managed transparently by the server operating system and is independent of any other client session.

When you deploy a Windows Application on an RD Session Host server instead of on each device, you have the following benefits:

Application deployment: You can quickly deploy Windows-based programs to computing devices across an enterprise. Remote Desktop Services is especially useful when you have programs that are frequently updated, infrequently used, or difficult to manage.

Application consolidation: Programs are installed and run from an RD Session Host server, eliminating the need for updating programs on client computers. This also reduces the amount of network bandwidth that is required to access programs.

Remote access: Your users can access programs that are running on an RD Session Host server from devices such as home computers, kiosks, low-powered hardware, and operating systems other than Windows.



139

REMOTE DESKTOP SERVICES (ROLE SERVICES)

Remote Desktop Services is a server role that consists of several role services. In Windows Server 2008 R2, Remote Desktop Services consists of the following role services:

RD Session Host: Remote Desktop Session Host (RD Session Host), formerly Terminal Server, enables a server to host Windows-based programs or the full Windows desktop. Users can connect to an RD Session Host server to run programs, to save files, and to use network resources on that server.

RD Web Access: Remote Desktop Web Access (RD Web Access), formerly TS Web Access, enables users to access RemoteApp and Desktop Connection through the Start menu on a computer that is running Windows 7 or through a Web browser.

RemoteApp and Desktop Connection provide a customized view of RemoteApp programs and virtual desktops to users.

RD Licensing: Remote Desktop Licensing (RD Licensing), formerly TS Licensing, manages the Remote Desktop Services client access licenses (RDS CALs) that are required for each device or user to connect to an RD Session Host server. You use RD Licensing to install, issue, and track the availability of RDS CALs on a Remote Desktop license server.

RD Gateway: Remote Desktop Gateway (RD Gateway), formerly TS Gateway, enables authorized remote users to connect to resources on an internal corporate network, from any Internet-connected device.

RD Connection Broker: Remote Desktop Connection Broker (RD Connection Broker), formerly TS Session Broker, supports session load balancing and session reconnection in a load-balanced RD Session Host server farm. RD Connection Broker is also used to provide users access to RemoteApp programs and virtual desktops through RemoteApp and Desktop Connection.



139

Internet

RD Session Host 1

Modem

Internal RD Clients

External RD Clients

RD Servers

RD Services

2008 R2

PLCs

Terminal Server

2008 R2

InTouch Application

IO Server

Terminal S

erver

2008 R2

RDP\ICA protocols is used to view the InTouch session

RD Session Host 2

InTouch Application

Terminal Server

2008 R2

RD Gateway

RD Broker RD Web Access

RD Web AccessService Installed

RD Broker Service Installed

RD Session Host Service Installed

RD GatewayService Installed


Terminal Services 2008 R2


Terminal Services 2008 R2



139

INSTALLING REMOTE DESKTOP SERVICES

Installing Remote Desktop Services is accomplished by completing the following tasks:

INSTALL REMOTE DESKTOP SERVICES (ROLE)

1. To begin the installation, click Start/Administrative Tools/Server Manager (It’s assumed that a dedicated Windows 2008 R2 server has been setup).

2. Click Roles in the left navigation pane and then click Add Roles in the right pane. The Add Roles Wizard appears.

3. Click Next, then click Remote Desktop Services as the role to install on this server.

http://sharepointgeorge.com/wp-content/uploads/2009/11/clip_image002.jpg

http://sharepointgeorge.com/wp-content/uploads/2009/11/clip_image003.png


http://sharepointgeorge.com/wp-content/uploads/2009/11/clip_image003.png



139

4. Click Next. The Remote Desktop Services wizard appears.

5. Click Next.




139

INSTALL SPECIFIC REMOTE DESKTOP SERVICES

1. On the Select Server Roles panel, click Remote Desktop Services and then Next to select the specific services required.

A warning message appears and recommends that any applications intended to be accessed by remote desktop users not be installed until the Remote Desktop Services role has been installed.

2. Click Next to proceed to the authentication selection screen. Click Require Network Level Authentication to prevent users running on older operating systems without Network Level Authentication from accessing Remote Desktop Services. Network Level Authentication essentially performs authentication before the remote session is established. If less strict authentication is acceptable, or some users are running older operating systems, they do not require Network level Authentication. This option must be selected before clicking Next.

The Specify Licensing Mode screen allows you to define the licensing method. When Configure later is selected, a 120-day grace period allows the system

http://www.techotopia.com/index.php/Image:Windows_server_2008_r2_remote_desktop_services_install.jpg



139

to be used without providing licenses. This means you must provide licensing within 120 days.

For Per Device mode, you are allowed a specified number of devices to connect to the service at any one time regardless of who the users are.

The Per User option restricts access to the specified users, regardless of the device from which they are connecting.

3. Select the Configure later option and click Next.

Next, specify the users and groups allowed to access the RD Session Host. Users can be added and removed at any time by changing the members of the Remote Desktop Users Group. Click Add to add additional users.

The final wizard allows you to define the user experience. This wizard essentially controls whether or not audio, video and desktop effects (such as the Aero user interface) are enabled on the users’ remote desktops.

These features are not enabled by default because they consume considerable amounts of bandwidth and place an extra processing load on the RD Session Hosts.

http://www.techotopia.com/index.php/Image:Windows_server_2008_r2_remote_desktop_services_licensing.jpg



139

Unless you need users to be able to stream audio (both to and from the session host) and video to the remote desktops and use the latest graphics-intensive desktop effects, it is recommended that these features remain disabled:

4. Click Next. You see the Confirmation screen. Read any warnings carefully. The wizard typically recommends any currently-installed applications should be re-installed before remote access is provided to users.

5. Click Install to begin the installation process.

You must restart the Windows Server 2008 R2 system partway through the installation. After the reboot, be sure to log in as the same administrative user to complete the Remote Desktop Services configuration process. Once the process is complete, the Installation Results window appears (following figure).

6. Click Close.

http://www.techotopia.com/index.php/Image:Windows_server_2008_r2_remote_desktop_services_experience.jpg

http://www.techotopia.com/index.php/Image:Windows_server_2008_r2_remote_desktop_services_installed.jpg

http://www.techotopia.com/index.php/Image:Windows_server_2008_r2_remote_desktop_services_experience.jpg

http://www.techotopia.com/index.php/Image:Windows_server_2008_r2_remote_desktop_services_installed.jpg



139

INTOUCH FOR TERMINAL SERVICES

InTouch for Terminal Services allows you to leverage the benefits of Windows 2008 Terminal Services in an industrial environment. With Terminal Services, InTouch processing is moved completely off the operator's workstation and onto a centralized server.

WHY INTOUCH FOR TERMINAL SERVICES?

InTouch for Terminal Services allows InTouch to run in a multi-user environment. For organizations wanting to increase flexibility in process visualization and to control operator workstation management costs, the InTouch for Terminal Services architecture offers an important enhancement to the traditional two- or three-tier client-server architecture.

TERMINAL SERVICES BENEFITS FOR INTOUCH

Beyond cost and scalability improvements, InTouch for Terminal Services also provides many technological advantages. For example, you can remotely control an InTouch application for quick troubleshooting and operator training.

Using Microsoft's new Remote Desktop Gateway (RD Gateway) you can view your process over the web for a super-thin client, full InTouch experience. You can also provide roaming operators with real-time information and control by using wireless Ethernet.

Lastly, using InTouch for Terminal Services with Windows CE and Mobile provides a full desktop experience on hardware that would otherwise be unable to support such operating systems.

Windows CE and Mobile clients are generally dedicated purpose devices. Due to InTouch licensing and hardware requirements, full-featured HMI functionality has not been available for Windows CE and Mobile applications. InTouch for Terminal Services fully supports very thin hardware ‟ hardware with fewer components than a desktop computer. Not only are these clients less likely to fail, they can be replaced, which reduces the overall MTTR (mean time to repair).



139

Centralized InTouch Management

By running InTouch applications on a terminal server, you only need one InTouch runtime program to be installed. Service packs, upgrades, and other related maintenance requirements are also done only once ‟ on the terminal server. All operators are ensured that they are using the current version of InTouch.

Accordingly, the costs and challenges of updating workstation machines, especially for remote workstations, are significantly reduced. You can also reduce labor costs associated with software maintenance since only one computer (configured as a terminal server) requires InTouch and its applications to be installed.

New operator interfaces can be Windows-based Terminals or other thin client computers.

Beyond viewing the process, you can also remotely modify applications by connecting to the terminal server-based WindowMaker. Maintaining the same application version among different repositories is no longer necessary. WindowMaker does not currently support multiple users.

Note: Only one person can edit an application at any one time. If another person launches WindowMaker for the same application at the same time, it may become corrupt and/or unpredictable machine operation may result.

Reduced Hardware Costs

Terminal Services Clients (RDP Client) run on the following Microsoft platforms

Windows XP SP3

Vista SP2

Windows 7

RDP clients are also available for Windows CE and Windows Mobile.

With the integration of InTouch and Terminal Services, you can deploy the latest applications in a fully server-centric mode. By removing the processing and data storage tasks from the client machine, you can greatly extend the life of your existing hardware.

In some cases, the need to replace may not occur until the computer physically breaks down.



139

InTouch for Terminal Services and 3rd party industrial panel displays can also provide an economical alternative for process visualization in harsh environments. The increased cooling requirements and stronger construction typically make industrial panel displays more expensive than their desktop counterparts.

With Terminal Services, industrial hardware costs are reduced because you no longer need high-powered processors, extra memory, floppy or CD-ROM drives. Many industrial panel displays now provide the ability to boot and connect to a terminal server from memory, and therefore do not require the added expense of a hard drive. The lack of moving parts also extends the life of hardware.

If you need more robust hardware to replace the control panels, you can install industrial-grade computers. These machines only require the minimum components to run the emulation software, and therefore, can be purchased at a significantly reduced price.

Remote Access

Operators and other end-users gain access to a terminal server over any Transmission Control Protocol/Internet Protocol (TCP/IP) connection, including Remote Access, Ethernet, the Internet, wireless, wide area network (WAN), or virtual private network (VPN).

Due to the reduced bandwidth requirements of the RDP/ICA protocol, Terminal Services extends the capabilities of InTouch to users who would otherwise be unable to access Wonderware applications.

Wireless networks have traditionally been unable to support the large amount of process information for real-time monitoring and control. With InTouch for Terminal Services, applications can run with the same response time and performance as their counterparts that are directly connected to the local area network (LAN). You can therefore support real-time monitoring and control for their mobile operators. The client terminals need only the emulation software to connect to the terminal server. You can then simply launch WindowViewer to monitor the operation of choice.



139

Internet Access

Using Microsoft's new RD Gateway (introduced in Windows Server 2008), remote users can access a terminal server over the Internet. A Remote Desktop Gateway (RD Gateway) server is a type of gateway that enables authorized users to connect to remote computers on a corporate network from any computer with an Internet connection.

RD Gateway is based on the RDP feature set. RD Gateway uses the Remote Desktop Protocol (RDP) along with the HTTPS protocol to help create a secure, encrypted connection.

In earlier versions of Remote Desktop Connection, people couldn't connect to remote computers across firewalls and network address translators because port 3389†the port used for Remote Desktop connections†is typically blocked to enhance network security. However, an RD Gateway server uses port 443, which transmits data through a Secure Sockets Layer (SSL) tunnel.

The RD Gateway server provides these benefits:

Enables Remote Desktop connections to a corporate network from the Internet without having to set up virtual private network (VPN) connections.

Enables connections to remote computers across firewalls.

Allows you to share a network connection with other programs running on your computer. This enables you to use your ISP connection instead of your corporate network to send and receive data over the remote connection.

You can therefore support real-time monitoring and control for their mobile operators with either the Terminal Services Client software or by simply launching a web browser and connecting to remote computers on a corporate network, from any computer with an Internet connection.



139

Network Load Balancing (NLB) and Availability with Terminal Services

NLB distributes traffic across several servers by using the TCP/IP networking protocol. You can use NLB with a terminal server farm to scale the performance of a single terminal server by distributing sessions across multiple servers.

Remote Desktop Connection Broker (RD Connection Broker), formerly Terminal Services Session Broker (TS Session Broker), included in Windows Server® 2008 Standard, Windows Server 2008 Enterprise, and Windows Server 2008 Datacenter, keeps track of disconnected sessions on the terminal server farm, and ensures that users are reconnected to those sessions.

Additionally, RD Connection Broker enables you to load balance sessions between terminal servers in a farm. This functionality is provided by the RD Connection Broker Load Balancing feature. However, this session-based load balancing feature requires a front-end load balancing mechanism to distribute the initial connection requests to the terminal server farm.

You can use a load balancing mechanism such as DNS round robin, NLB or a hardware load balancer to distribute the initial connection requests. By deploying NLB together with RD Connection Broker Load Balancing, you can take advantage of both the network-based load balancing and failed server detection of NLB, and the session-based load balancing and per server limit on the number of pending logon requests that is available with RD Connection Broker Load Balancing.



139

REMOTE CONTROL

Remote Control is a Terminal Services feature that provides the ability to take control of another workstation in the event of a client hardware failure. Remote Control also provides an easy way to train operators and monitor operations without being physically next to the terminal.

You can therefore be confident that even though failures may occur, their impact on production will be a minimum. Remote Control enables a workstation to immediately take over another that has failed. By adding a second server and installing Network Load Balancing, all the sessions are protected.

Internet

RD Session Host 1

Modem

Internal RD Clients

External RD Clients

RD Servers

RD Services

2008 R2

PLCs

Terminal Server

2008 R2

InTouch Application

IO Server

Terminal S

erver

2008 R2


Terminal Services for InTouch

Benefits

Terminal Services for InTouch

Benefits

RD Session Host 2

InTouch Application

Terminal Server

2008 R2

RD Gateway

RD Broker RD Web Access

Web Access To

InTouch Applications

Manage Network

Load Balancing (NLB)

and Availability

Remote Access To

InTouch ApplicationsCentralized InTouch

Application Management

Manage Network Load

Balancing (NLB) and

Availability

Note: Wonderware strongly recommends that you consult a Microsoft professional and perform adequate testing before deploying load balancing into your production environment.



139

GETTING STARTED WITH INTOUCH FOR TERMINAL SERVICES

UNDERSTANDING INTOUCH FOR TERMINAL SERVICES


You can use InTouch for Terminal Services to run InTouch on one central server and supply InTouch functionality to multiple client computers without imposing any further software or hardware requirements on the client computers.

In this environment, the hardware and software requirements for the server are relatively high and those for the clients relatively low. This results in lower total cost of ownership (TCO) and lower ongoing operating expenses.

KEY POINTS

„ InTouch for Terminal Services uses the Remote Desktop Protocol (RDP) to communicate between clients and the InTouch Terminal Server.

„ Each client computer runs an individual InTouch session on the Terminal Server without interacting with other client sessions.

„ You can run an application that is developed for standard InTouch with InTouch for Terminal Services. No application changes are necessary.

„ You can use the Distributed Alarm system with InTouch for Terminal Services. Using the alarm client, you can select the alarm data and how to show it from WindowViewer for each Terminal Services session.

When an alarm is acknowledged in a Terminal Services environment, the Operator Node that gets recorded is the name of the client computer where the respective operator established the Terminal Services session.

In a typical Terminal Services architecture, application development, deployment, and client visualization are placed on separate computers.

It is recommended that you deploy a SINGLE Engine to the Remote Desktop Server, even if it is hosting different InTouch applications.

You must deploy each InTouch application to the server running InTouch for Terminal Services.

You run each managed InTouch application in a separate terminal services client session.



139

RUNNING INTOUCH APPLICATIONS IN A TERMINAL SERVICES ENVIRONMENT

You can run InTouch applications in Terminal Services Environment in the following ways.

STANDALONE INTOUCH FOR TERMINAL SERVICES CONFIGURATION CREATED USING

WONDERWARE WINDOWMAKER.

These are tag-based applications, contain no ArchestrA Graphic Symbols, and are not deployed. Client nodes running a Standalone application do not require an Application Server Platform.


You can use InTouch for Terminal Services to run InTouch on one central server and supply InTouch functionality to multiple client computers without imposing any further software or hardware requirements on the client computers. In this environment, the hardware and software requirements for the server are relatively high and those for the clients relatively low.

We highly recommend the use of Network Application Distribution (NAD) when running standalone InTouch applications in a Terminal Services environment.

Note: Configure NAD in Node Properties for each user that connects to InTouch for Terminal Services.

RUNNING A MANAGED INTOUCH APPLICATION WITH TERMINAL SERVICES

A Managed InTouch Application is an application that is created, edited and managed in the IDE and deployed to a Platform with a View Engine. Managed Applications can access Galaxy data as well as tag data and can contain ArchestrA Graphics. This is the recommended method for running an InTouch for Terminal Services environment in version 10.x.

You can run managed InTouch applications in a Terminal Services environment. The benefit of using Terminal Services is that it allows you to run multiple, autonomous InTouch applications simultaneously on a Terminal Server.



139

Best Practice: This is the recommended mode for Server 2008 R2 RDS implementation, even if the InTouch application is a Tag-Based application. Each client session manages its own instance of the application under \UserName\Application Data\ArchestrA\Managed App.



139

RUNNING A PUBLISHED INTOUCH APPLICATION WITH TERMINAL SERVICES

Published Applications are traditional InTouch for Terminal Services configurations, but are created and managed using the IDE and can include ArchestrA Graphic Symbols. Published applications are published, not deployed, and the client nodes running the published applications do not require an Application Server Platform.

Note: See Tech Note 538 at the end of this document for complete details.

Internet

Modem

RD Web Access

RD Gateway

Internal RD Clients

External RD Clients

RD Servers

RD Services

2008 R2

PLCs

IO Server

RD Broker

Terminal S

erver

2008 R2

`


Terminal Services Environment


Terminal Services Environment

RD Session Host 2

RD Session Host 1

InTouch Application

InTouch Application

Terminal Server

2008 R2

Terminal Server

2008 R2

Running Standalone InTouch Applications on RD Session Host

Running Managed InTouch Application on RD Session Host

Running Published InTouch Application on RD Session Host

Running InTouch ViewerOn TS Clients


TYPES OF INTOUCH FOR TERMINAL SERVICES

Available client computers range from desktop replacements to industrial display panels. They all connect to terminal server using a small client program installed on disk or in firmware. The choice of which client platform to use depends on the install-base and operator interface needs.

Your client computer must be able to communicate to terminal server using the RDP or ICA protocol. ACP-Enabled Thin Clients embed a version of ICA.

ACP ThinManager™ increases the available client types to non-Windows-based workstations, including UNIX, Linux, and industrial display panels. Consult a vendor to verify Wonderware support for a particular non-Windows-based operating system.

https://wdnresource.wonderware.com/support/kbcd/html/1/t002275.htm#s2



139

WINDOWS 2008/R2

Windows Server 2008 R2: Remote Desktop Services (formerly Terminal Services), is a server role in Windows Server® 2008 R2. This server role provides technologies which enable users to access Windows-based programs installed on a Remote Desktop Session Host (RD Session Host) server, or to access the full Windows desktop. With Remote Desktop Services, you can access an RD Session Host server from within a corporate network or from the Internet.

RD Clients running Remote InTouch App

Corporate Network

Remote Desktop ServicesWindows 2008 / R2

RD Server

InTouch Application

Remote Desktop Services lets you efficiently deploy and maintain software in an enterprise environment. You can easily deploy programs from a central location. Because you install the programs on the RD Session Host server and not on the client computer, programs are easier to upgrade and to maintain.

TERMINAL SERVICES BEHAVIOR IN WINDOWS SERVER 2008

In a change from Windows Server 2003, Windows Server 2008 no longer supports 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, Session 0 is no longer an interactive session, and is reserved only for Windows services. Windows Server 2008 treats all remote connections as remote RDP sessions regardless of /console, /admin, or any other switches used to make the connection.

This impacts InTouch functionality such as Alarm Manager that depends on the Terminal Server Console session. Refer to the InTouch 10.1 SP2 Readme for further information about InTouch applications running in the Terminal Server Console.

The impact to Application Server operations is minimal, since most Application Server processes run as services. However, one impact to Application Server is to carry forward the restriction introduced with the Windows Vista operating



139

system, which permits only one alarm provider. While both Application Server and InTouch can be configured as alarm providers, only one alarm provider is supported.

ACP THIN MANAGER

ACP ThinManager offers a centralized management solution for the modern factory & office by simplifying management of application and visual sources.

InTouch can be delivered via ACP ThinManager

ACP

ThinManager

Server

Thin Clients running Remote InTouch App

Corporate Network

InTouch Application

This allows unprecedented control and security in a sustainable and scalable platform. ThinManager's thin client architecture allows for deployment of less expensive hardware while giving users the applications and tools familiar to them in a format that reduces management costs and increases security.

ThinManager lets you configure, maintain, upgrade and replace client devices on your network quickly and efficiently. Its intuitive Windows Explorer-like interface provides At-A-Glance Management of all connected ThinManager-Ready Thin Clients and Terminal Servers.

Because ThinManager is a Thin Client enabling technology, each connected ThinManager-Ready Thin Client device is guaranteed to have the same internal software, assuring uniformity of operation across a wide variety of models.



139

HOW THINMANAGER WORKS

Display Clients can be generated by a traditional session running on a Terminal Server, a shadowed thin client, an image from an IP camera or VMWare® virtual machines. The sources of these displays are referred to as Display Servers.

ThinManager's MultiSession core technology allows you to view multiple Display Clients with a single thin client. Using session tiling you can even view up to 25 Display Clients on a single monitor.

TermSecure extends this functionality even more by allowing you to link Display Clients to a user instead of to a particular thin client. Users can then access their own displays simply by authenticating to any ThinManager-Ready thin client.

ThinManager renders display clients through a number of different types of thin client hardware available from multiple manufacturers.

ThinManager from ACP adds server-side management features including auto-creation, replacement, feature grouping, and downloadable modules for simpler configuration and greater functionality in a Terminal Services Environment



139

PLANNING CONSIDERATIONS FOR TERMINAL SERVER

APPLICATIONS

SYSTEM REQUIREMENTS

The following system specifications are supported. The following information was derived from the specific test plan and is not intended as a limitation.

TSE Platforms (10 Platforms)

Hardware: 2.8 GHz with 2 GB RAM, 1 GB network switch

Software: Distributed (refer to the following graphic)

Windows Server 2003 SP2 (32 and 64-bit version)

Windows 7 and SP1

Windows Server 2008 R2 and SP1

In Wonderware tests, the TSE Platforms were used for client connection only. The Platforms did not have App Engines. Each Platform was configured to be an alarm provider and was filtered to subscribe to eleven Areas. Each Platform was deployed to a Terminal Services machine. The ten Platforms serviced ten client connections each.

Client Nodes (10 Nodes with 100 Client Connections)

Hardware: 2.8 GHz CPU with 1 GB RAM, 1 GB network switch

Software: Distributed (refer to the following graphic)

Windows XP SP3 (32-bit only)

Windows Vista SP2 (32/64-bit)

Windows Server 2003 SP2 Standard and Enterprise (32-bit version)

Windows 7 and SP1

Windows Server 2008 R2 and SP1



139

Important: We recommend that you install applications on a test server before you deploy them in your production environment.

Before you install Terminal Services, make sure the following checklist is complete:

Identify the client applications (for example, Wonderware InTouch) that you need to install on the server.

Identify the hardware requirements for your clients.

Determine the server configuration required to support clients.

Identify the licenses required for Terminal Services as well as other applications that you will be running.

Understand how some aspects of InTouch applications run under Terminal Services, such as alarms, security, I/O, and scripts.



139

WORKING WITH NETWORK LOAD BALANCING

Network Load Balancing (NLB) distributes traffic across several servers by using the TCP/IP networking protocol. You can use NLB with a terminal server farm to scale the performance of a single terminal server by distributing sessions across multiple servers.

ABOUT THE NETWORK LOAD BALANCING FEATURE

The NLB feature in Windows Server 2008 R2 enhances the availability and scalability of Internet server applications such as those used on Web, FTP, firewall, proxy, virtual private network (VPN), and other mission-critical servers. A single computer running Windows Server 2008 R2 provides a limited level of server reliability and scalable performance. However, by combining the resources of two or more computers running one of the products in Windows Server 2008 R2 into a single virtual cluster, an NLB can deliver the reliability and performance that Web servers and other mission-critical servers need.

ABOUT REMOTE DESKTOP CONNECTION BROKER

Remote Desktop Connection Broker keeps track of user sessions in a load-balanced Remote Desktop Session Host server farm. The Remote Desktop Connection Broker database stores session information, (including the name of the Remote Desktop Session Host server where each session resides), the session state for each session, the session ID for each session; and the user name associated with each session.

Remote Desktop Connection Broker uses this information to redirect a user who has an existing session to the Remote Desktop Session Host server where the user’s session resides.

Remote Desktop Connection Broker is also used to provide users with access to RemoteApp and Desktop Connection. RemoteApp and Desktop Connection provide a customized view of RemoteApp programs and virtual desktops. Remote Desktop Connection Broker supports load balancing and reconnection to existing sessions on virtual desktops accessed by using RemoteApp and Desktop Connection. To configure the Remote Desktop Connection Broker server to support RemoteApp and Desktop Connection, use the Remote Desktop Connection Manager tool. For more information, see the Remote Desktop Connection Manager Help in Windows Server 2008 R2.

Remote Desktop Connection Broker that is used in an NLB setup is included in Windows Server® 2008 R2 Standard, Windows Server 2008 R2 Enterprise and Windows 2008 R2 Datacenter.

The NLB feature is included in Windows Server 2008 R2. You do not require a license to use this feature.



139

You need a Microsoft TS license for managing the remote desktop terminal server sessions.

ABOUT MANAGED INTOUCH APPLICATIONS WITH NETWORK LOAD BALANCING

The features provided by Remote Desktop are made available through the Remote Desktop Protocol (RDP). RDP is a presentation protocol that allows a Windows-based terminal (WBT), or other Windows-based clients, to communicate with a Windows-based Terminal Server. RDP is designed to provide remote display and input capabilities over network connections for Windows-based applications running on your Windows XP Professional desktop.

In this topology, clients can access the InTouch System Platform node via Remote Desktop. Whenever a new connection is requested to the InTouch System Platform Node, a new session is created. So all the traffic goes to the system platform node and degrades the performance of the InTouch node.

The following figure displays a topology without Network Load Balancing (NLB):

Domain Network

Client Machine Client Machine Client Machine

InTouch Node

Connects to the InTouch Node via Remote Desktop

Network Load Balancing distributes IP traffic to multiple copies (or instances) of a TCP/IP service, such as a Web server, each running on a host within the cluster.

Network Load Balancing transparently partitions the client requests among the hosts and enables the client to access the cluster using one or more "virtual" IP addresses. The cluster appears to be a single server that answers these client requests.



139

The following figure displays a topology with Networking Load Balancing:

Domain Network


Connects to the NLB Cluster Node via Remote Desktop

Domain Network

InTouchNode

InTouchNode

NLB Cluster

Remote Session BrokerNode

Note: The Remote Desktop Connection Broker shown as a separate node in the above topology can be configured on one of the NLB cluster nodes itself.

You can leverage the load balancing for InTouch-managed applications.



139

To configure an NLB for managed InTouch application

1. Configure one VM or Physical machine with Wonderware Application Server

2. On both the NLB cluster nodes, install InTouch TS with Terminal Server license.

3. Configure an NLB cluster as explained below.

4. On Wonderware Application Server node, develop managed InTouch application and deploy it on each of the NLB Cluster node.

Configuring an NLB for InTouch System Platform nodes allows you to combine application servers to provide a level of scaling and availability that is not possible with an individual server.

NLB distributes incoming client requests to InTouch System Platform nodes among the servers in the cluster to more evenly balance the workload of each InTouch System Platform server and prevent overload on any InTouch System Platform server. To client computers, the NLB cluster appears as a single server that is highly scalable and fault tolerant.

SETTING UP A NETWORK LOAD BALANCING CLUSTER

To setup an NLB:

1. Prepare two VM nodes that are remote desktop-enabled and have Windows Server 2008 R2 Operating System.

2. Assign static IPs to both nodes.

Note: NLB disables Dynamic Host Configuration Protocol (DHCP) on each interface it configures, so the IP addresses must be static.



139

TOPOLOGY 1: LEVERAGING NETWORK LOAD BALANCING BY CONFIGURING REMOTE

DESKTOP CONNECTION BROKER ON ONE OF THE NLB CLUSTER NODES

You can configure an NLB cluster configuring the Remote Desktop Connection Broker on one of the NLB cluster nodes.

Domain Network



Domain Network

InTouchNode

InTouchNode

NLB Cluster



139

To configure NLB with Topology 1

1. On each of the cluster nodes install Remote Desktop Services. For more information, refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN. Note: On the Select Role Services screen, select Remote Desktop Session Host and Remote Desktop Connection Broker on one of the Cluster Nodes to configure it as NLB Cluster node as well as RD connection broker node. On the other NLB Cluster node, select only Remote Desktop Session Host.

2. On each of the cluster nodes, install Network Load Balancing. For more information, refer to "Installing Network Load Balancing" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

3. On the NLB cluster node which is configured as RD connection broker as well, add a Remote Desktop Session Host Server. For more information, refer to "Adding a Remote Desktop Session Host Server" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

4. On each of the cluster nodes, create a Network Load Balancing Cluster. For more information, refer to "Creating a Network Load Balancing Cluster" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

5. On each of the cluster nodes, configure Remote Desktop Connection Broker Settings. For more information, refer to "Configuring Remote Desktop Connection Broker Settings" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

https://wdn.wonderware.com/sites/WDN/Lists/Article/DispForm.aspx?ID=367









139

TOPOLOGY 2: LEVERAGING NETWORK LOAD BALANCING BY CONFIGURING REMOTE

DESKTOP CONNECTION BROKER ON A SEPARATE NODE

Instead of configuring the Remote Desktop Connection Broker on one of the NLB cluster nodes, you can also configure the Remote Desktop Connection Broker on a separate node.

Domain Network



Domain Network

InTouchNode

InTouchNode

NLB Cluster

Remote Session BrokerNode



139

To configure NLB with Topology 2

On the NLB Cluster nodes, do the following:

1. Install Remote Desktop Services. For more information refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

Note: In the Select Role Services screen, select Remote Desktop Session Host on the NLB Cluster nodes.

2. Install Network Load Balancing. For more information, refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

3. Create a Network Load Balancing Cluster. For more information, refer to "Creating a Network Load Balancing Cluster" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

4. Configure remote desktop connection broker settings. For more information, refer to "Configuring Remote Desktop Connection Broker Settings" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

On the Remote Desktop Connection Broker Node do the following:

1. Install Remote Desktop Services. For more information, refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

Note: On the Select Role Services screen, select only Remote Desktop Connection Broker on the Remote Desktop Connection Broker Node.

2. Add a Remote Desktop Session Host Server. For more information, refer to "Adding a Remote Desktop Session Host Server" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.









139

INSTALLING REMOTE DESKTOP SERVICES

Remote Desktop Services, earlier called Terminal Services, provides technologies that enable access to session-based desktops, VM-based desktops, or applications in the datacenter from both within a corporate network and the Internet. Remote Desktop Services enables a rich-fidelity desktop or application experience, and helps to securely connect remote users from managed or unmanaged devices.

To install Remote Desktop Services

1. Open the Server Manager window.

2. On node 1, click Start, point to Administrative Tools, and then click Server Manager. The Server Manager window appears.

3. Add the required role services.

a. On the Server Manager window, click Roles. The Roles area appears.

b. Click Add Roles. The Before You Begin screen in the Add Features Wizard window appears.



139

c. Click Next. The Select Server Roles screen appears.

d. Click the Remote Desktop Services check box, and then click Next. The Remote Desktop Services screen appears.



139

e. Click Next. The Select Role Services screen appears.

f. Select the Remote Desktop Session Host and Remote Desktop Connection Broker check boxes, and then click Next. The Uninstall and Reinstall Applications for Compatibility screen appears.



139

g. Click Next. The Specify Authentication Method for Remote Desktop Session Host screen appears.

h. Click the Do not require Network Level Authentication option, and then click Next. The Specify Licensing Mode screen appears.



139

i. Click the Per User option or Per Device option based on license availability, and then click Next. The Select User Groups Allowed Access To This Remote Desktop Session Host Server screen appears.

You can choose two types of Windows Client Access Licenses: device-based or user-based, also known as Windows Device CALs or Windows User CALs.



139

This means you can choose to acquire a Windows CAL for every device (used by any user) accessing your servers, or you can choose to acquire a Windows CAL for every named user accessing your servers (from any device).

4. Confirm the details you entered, and install the services.

a. On the Select User Groups Allowed Access To This Remote Desktop Session Host Server screen, click Next. The Configure Client Experience screen appears (see page 582 of the Wonderware ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN).




139

INSTALLING NETWORK LOAD BALANCING

You need to install an NLB on the network adapter that you want to use for the Remote Desktop Protocol (RDP) connection.

To install an NLB


2. Click Start, point to Administrative Tools, and then click Server

Manager. The Server Manager window appears.

3. On the Server Manager window, click Features. The Features pane appears.

4. Click Add Features. The Select Features screen in the Add Features Wizard window appears.



139

5. Click the Network Load Balancing item, and then click Next. The Confirm Installation Selections screen appears.

6. Click Install.



139

ADDING A REMOTE DESKTOP SESSION HOST SERVER

A Remote Desktop Session host (RD Session Host) server hosts Windows-based programs or the full Windows desktop for Remote Desktop services client. You can connect to a Remote Desktop Session Host server to run programs, save files, and use network resources on this server.

You can access a Remote Desktop Session Host server by using Remote Desktop Connection or RemoteApp.

You can add a Remote Desktop Session Host server to the connection broker computers’ local group.

To add an RD Session Host server


2. Click Start, point to Administrative Tools, and then click Server Manager. The Server Manager window appears.

Add a group to the Remote Desktop Session Host server.

3. On the Server Manager window, expand Configuration, then Local Users and Groups. Click Groups. The Groups area appears.



139

4. Right-click the Session Broker Computers group, and then click Properties. The Properties window for the selected group appears.

5. Click Add. The Select Users, Computers, or Groups window appears.



139

6. Click Object Types. The Object Types window appears.

7. Select Computers, then click OK. The node names of the computer appear in the Select Users, Computers, or Groups window.

8. Click OK to add the computer account for the Remote Desktop Session Host server.

CREATING A NETWORK LOAD BALANCING CLUSTER

To configure an NLB cluster, you need to configure the following parameters:

Host parameters that are specific to each host in an NLB cluster.

Cluster parameters that apply to an NLB cluster as a whole.

Port rules

Note: You can also use the default port rules to create an NLB cluster.

To create an NLB cluster

1. Open the Network Load Balancing Manager window.

2. On node 1 of the required VM with NLB, click Start, point to Administrative Tools, and then click Network Load Balancing Manager. The Network Load Balancing Manager window appears.

3. Connect the required host to a new cluster by right-clicking Network Load Balancing Clusters, and then clicking New Cluster.



139

The New Cluster : Connect window appears.

4. In the Host box, type the name of the host (node 1), and then click Connect.



139

5. Under Interfaces available for configuring a new cluster, select the interface to be used with the cluster, and then click Next. The Host Parameters section in the New Cluster window appears.

6. Type the relevant details and create the new cluster.

7. In the Priority list, click the required value, and then click Next. The Cluster IP Addresses section in the New Cluster window appears.



139

Note: The value in the Priority box is the unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles the entire cluster's network traffic that is not covered by a port rule. You can override these priorities or provide load balancing for specific ranges of ports by specifying the rules on the Port rules tab of the Network Load Balancing Properties window.

8. Click Add to add a cluster IP address. The Add IP Address window appears.

9. Click the Add IPv4 address option.

10. Type the new cluster static IP address and the Subnet mask.



139

11. Click OK to close the window. The IP address appears on the Cluster IP Addresses section of the New Cluster window.

12. Click Next. The Cluster Parameters section for the New Cluster window appears.

13. Type the name of the new cluster.

14. Click the Multicast option. Note: When you click the Unicast option, NLB instructs the driver that belongs to the cluster adapter to override the adapter's unique, built-in network address and change its MAC address to the cluster's MAC address. Nodes in the cluster can communicate with addresses outside the cluster subnet. However, no communication occurs between the nodes in the cluster subnet. When you click the Multicast option, both network adapter and cluster MAC addresses are enabled. Nodes within the cluster are able to communicate with each other within the cluster subnet, and also with addresses outside the subnet.

15. Click Next. The New Cluster : Port Rules window appears.



139

16. Click Finish to create the cluster and close the window. The Network Load Balancing Manager window appears (below).

Add another host to the cluster.

1. Right-click the newly-created cluster and then click Add Host to Cluster.

The Add Host to Cluster : Connect window appears.



139

2. In the Host field, type the name of node 2, then click Connect.

3. Under Interfaces available for configuring a new cluster, click the interface name to be used with the cluster, then click Next. The New Cluster : Host Parameters window appears.

4. Type the priority value, and then click Next.



139

The Port Rules section of the Add Host to Cluster window appears.

5. Click Finish to add the host and close the window. The Network Load Balancing Manager window appears. The statuses of both the hosts are displayed.

To add users to the Remote Desktop Users group to access Network Load Balancing Cluster

1. On the Start menu, click Control Panel, System and Security then System Remote settings. The System Properties window appears.



139

2. Under Remote Desktop, click the relevant option to specify the remote desktop versions you want to allow access to.

3. Click Select Users to provide access to the system. The Remote Desktop Users window appears.

4. Select the users you want to allow access to, click Add, and then OK.

Note: The users can be local users and need not be domain users/administrators. If the users are local users they should be added on both the NLB cluster nodes with same user name and password.

CONFIGURING REMOTE DESKTOP CONNECTION BROKER SETTINGS

Remote Desktop Connection Broker, earlier called Terminal Services Session Broker (RD Connection Broker), is a role service that enables you to do the following:

„ Reconnect to existing sessions in a load-balanced Remote Desktop Session Host server farm. You cannot connect a different Remote Desktop Session Host server with a disconnected session and start a new session

„ Evenly distribute the session load among Remote Desktop Session Host servers in a load-balanced Remote Desktop Session Host server farm.

„ Access virtual desktops hosted on Remote Desktop Virtualization host servers and RemoteApp programs hosted on Remote Desktop Session Host servers through RemoteApp and Desktop Connection.

To configure Remote Desktop connection broker settings



139

1. Open the Remote Desktop Session Host Configuration window.

2. Click Start, Administrative Tools, Remote Desktop Services, then Remote Desktop Session Host Configuration. The Remote Desktop Session Host Configuration window appears.

3. In the Edit settings area, under Remote Desktop Connection Broker, double-click Member of farm in RD Connection Broker.

The Properties window appears.



139

4. Click Change Settings.

The RD Connection Broker Settings window appears.

5. Click the Farm member option.



139

6. In the RD Connection Broker server name box, type the node name where the RD Connection Broker is installed.

7. In the Farm Name box, type the farm name that you want to join in the Remote Desktop Session Broker, and then click OK.

8. In the Properties window, click Participate in Connection Broker Load Balancing.

9. Type the value for the Relative weight of this server in the farm.

By assigning a relative weight value, you can distribute the load between more powerful and less powerful servers in the farm. By default, the weight of each server is 100. You can modify this value as required.

10. Under Select IP addresses to be useful for reconnection, click IP address you provided while creating the cluster, and then click OK.

11. Click OK to acknowledge the confirmation/warning.



139

Repeat this procedure on Node 2. Ensure that you enter the same details in each step for Node 2 as you did for Node 1. In the Farm Name box, type the same Farm Name used while configuring Node 1.

DISCONNECTING FROM AND CONNECTING TO A REMOTE DESKTOP SESSION

If you disconnect from a session (whether intentionally or because of a network failure), the applications you were running will continue to run. When you reconnect, the Remote Desktop Connection Broker is queried to determine whether you had an existing session, and if so, on which Remote Desktop Session Host server. If there is an existing session, Remote Desktop Connection Broker redirects the client to the Remote Desktop Session Host server where the session exists.

With Remote Desktop Connection Broker Load Balancing, if you do not have an existing session and you connect to a Remote Desktop Session Host server in the load-balanced Remote Desktop Session Host server farm, you will be redirected to the Remote Desktop Session Host server with the fewest sessions. If you have an existing session and you reconnect, you will be redirected to the Remote Desktop Session Host server where your existing session resides. To distribute the session load between more powerful and less powerful servers in the farm, you can assign a relative server weight value to a server.

VIEWING CONNECTED SESSIONS

You can use Remote Desktop Services Manager to view sessions connected to each node of the NLB cluster, and view information and monitor users and processes on Remote Desktop Session host (RD Session Host) servers.

To view sessions connected to each node of the cluster

On any node of NLB, open the Remote Desktop Services Manager window.

1. Click Start, point to Administrative Tools/Remote Desktop Services, and then click Remote Desktop Services Manager. The Remote Desktop Services Manager window appears.

2. Create a new group by right-clicking Remote Desktop Services Manager, and clicking New Group. The Create Group window appears.



139

3. Type a name for the group and click OK to close the window. The name can be anything.

Add the required computers to the group.

1. In the left pane, right-click the newly created group, and then click Add Computer. The Select Computer window appears.

2. Click the Another Computer option.

3. In the Another computer box, type the computer name, and then click OK.

The Remote Desktop Services Manager window appears.

Note: You can either type or click Browse to select the required node name.

Repeat the previous steps to add other node names of the cluster to the newly-created group.



139

You can now select the group names in the left pane and view the sessions connected to each node of the cluster.



139

WONDERWARE LICENSING

Licenses for Wonderware products are maintained in license files or on a license server. The license file contains one or more license components, which are lines of information that specify licensing for an individual product.

Each license component is assigned a unique part number and contains information such as the:

Product name

Serial number

Type and duration of license

Number of seats and other information.

LICENSE TYPES

There are two kinds of licenses, unserved and served. For this document, only unserved licenses are included, since InTouch does not use Served (server-based) licensing.

Unserved licenses, also known as local licenses, are installed on the same computer as the applications using them. Unserved licenses do not run on a license server. Unserved license files usually have the file names wwsuite.lic or ArchestrA.lic.



139

Information about the license Type appears with the license name and license components when you view it in the ArchestrA License Manager.

Products can have a demonstration period, which allows you to run the specified application for a defined period when the license is not available. Licenses can also define a grace period, which is entered when a license is unavailable. The grace period is a limited time period tracked by the application. The application determines what happens during the grace period.

HOW WONDERWARE SOFTWARE USES LICENSES

When a Wonderware application starts, it looks for an unserved license on the same computer in the background. If no license is found locally, the application searches all license servers specified in ArchestrA License Manager for the computer.

When a license file is found, the application checks that this version is licensed for use. If more than one license is found, the order in which licenses are acquired by applications is:

Unserved licenses

Named device licenses

Named user licenses

Concurrent licenses

Unserved (locally installed) Licenses (WWSuite.lic and ArchestrA.lic)

Locally installed Server Licenses ArchestrAServer.lic (not used by InTouch)

Remote license Servers (Not applicable for this document)



139

If the application is not supported by the license or if the required license is not found, the software component defaults to either a demonstration mode or an absent license mode.

WONDERWARE CAL (CLIENT ACCESS LICENSE)

A CAL is not a software product. It is a license that gives a user the permission to access the services of a database server. It is a paper license!

CALs are used to connect with a database Server like

WW Historian Server (WWCAL)

Information Server (WWCAL)

MS SQL Server (MSCAL)

A client always needs a WWCAL when connecting to a WW Historian and always needs a MSCAL when connecting to a MSSQL database.

There are 4 types of WW CAL that include the MS CAL:

WW Basic CAL for per device, per user, per seat

WW Basic CAL per processor.

WW Enterprise CAL for per device, per user, per seat.

WW Enterprise CAL per processor.

WHEN YOU NEED A CAL

Active Factory or InTouch to connect to Historian Server

IS Standard and Advanced Client to connect to Information Server

Any node (WW node or third party software) connecting to Historian Server or MS SQL Server

InTouch, Active Factory, Wonderware Information Server Client

InBatch Server

InTrack Server

INTOUCH RUNTIME TSE LICENSE FILE

WWSUITE.LIC is a license file name that contains the InTouch_ feature line to enable InTouch (Dev, RT, Tag Count).

It also contains the InTouch_TSE_ feature line, which enables InTouch Terminal Services capability, enforces number of terminal server sessions as well as Bitstring that indicates the number of sessions licensed.



139

How InTouch for Terminal Services Licenses Work

Every session/instance of InTouch must be licensed, whether that instance is running on a remote computer or on the Terminal Server as a session. An instance of InTouch can be a terminal services session on a remote computer or InTouch running on the Terminal Server.

InTouch 10.1 and above do not include a separate DVD for InTouch for Terminal Services . For InTouch for Terminal Services, make sure the server was configured as a terminal server.

CAUTION: If you exceed the number of allowed sessions you will see the following error message: The number of allowed TSE count already exceeded.

InTouch for Terminal Services v10.1 License Example

In the following graphic

„ InTouch Runtime TSE 3 Client Description

„ Microsoft Terminal Services

„ 1 Terminal Server

„ 3 HMI TS display devices without IO capability (use IO on Terminal Server)

„ All HMI sessions are running the same Application so the same Tag count

„ No HMI view on Terminal Server

„ Terminal Server acts as a Device Integration IO Server

NODE QTY LICENSE DESCRIPTION

1 2 3&4

1 1 2

IO SERVER INTOUCH RUNTIME 3K TAGS WITHOUT I/O TSE

V10.1 INTOUCH RUNTIME 3K TAGS WITHOUT I/O TSE

V10.1



139

PLCs

3

No Intouch Session

at console

Windows 2008

R2 Serv

er with

Remote Deskto

p

InTouch RT TSE

Session 1 – 3K

Tags

InTouch RT TSE

Session 1 – 3K

Tags

InTouch RT TSE

Session 1 – 3K

Tags

4

2

1



139

INSTALLING THE INTOUCH FOR TERMINAL SERVICES LICENSE

To install InTouch for Terminal Services license you can use License utility or License Manager Server software.

License Manager Server software manages Server-based licenses.

It is installed with several Wonderware products, or as a separate install.

Setup is found on the Active Factory CD and the Wonderware Information Server CD.

You can find it on the System Platform 2012 DVD on this path: CD:\WIS\LicenseServer.

Note: The WWSuite.lic is not required on InTouch version 10.5 or higher. Only the ArchestrA.lic is used.



139

REMOTE DESKTOP LICENSING

Remote Desktop Licensing (RD Licensing), formally Terminal Services Licensing (TS Licensing) manages the Remote Desktop Services client access licenses (RDS CALs) that are required for each device or user to connect to a terminal server.

You use TS Licensing to install, issue, and track the availability of RDS CALs on a Remote Desktop Services license server.

When a client†either a user or a device†connects to a RD Session Host server, the RD Session Host server determines if a RDS CAL is needed. The RD Session Host server then requests a RDS CAL from the Remote Desktop Services license server on behalf of the client attempting to connect to the RD Session Host server. If an appropriate RDS CAL is available from a license server, the RDS CAL is issued to the client, and the client will be able to connect to the RD Session Host server.

Note: Remote Desktop Services Licensing is additional to other licenses that might be needed, such as FactorySuite licenses, operating system licenses, and any BackOffice family Client Access Licenses.

If you purchase ThinManager™ from ACP, it only includes the necessary licenses to run ThinManager. The licenses mentioned above are still required.



139

PLANNING SECURITY IN A TERMINAL SERVICES ENVIRONMENT

Use Application security to secure your InTouch application, Wonderware Historian, and other sensitive information systems.

Use the $Operator system tag to secure your application. You can then control operator access to specific functions by linking those functions to internal tags.

Replace the GetNodeName() function with the newer TseGetClientId() function to identify the client computer.

When using Terminal Services, the GetNodeName() function returns the name of the terminal server, not the name of the client computer.

Use security auditing to monitor intrusion attempts. If you suspect that your system is under any sort of attack, then you can enable logging for an array of auditable events. By default, security logging/auditing is disabled because it usually requires excessive processing resources.

Caution: Security auditing requires significant resources. Enable auditing when you evaluate your pilot server to accurately estimate your InTouch application hardware requirements.

DEFINING SECURITY

A proper security implementation is a critical component of any computer based control system. Of course, security is not simply to protect against malicious attack, but more often from human error. Often, a major problem is introduced by a simple mistake. On a terminal server, you cannot afford to provide the operators with the opportunity to make such mistakes.

Without proper security, users can have access to any directory and file on the server, including important system files and InTouch applications.

PHYSICAL SECURITY

Physical security addresses the operating environment of your servers and connected client systems.

Place your terminal server in a protected room that is free from physical threat and adverse conditions. Make the room available only to authorized (trusted) personnel.

Develop a schedule to back-up data and publish procedures on how to restore it.

Evaluate your risk if the terminal server goes down. Hardware protection such as surge suppressors, uninterruptible power supplies, and redundant servers will help keep your system running. Network Load Balancing or



139

systems with Assured Availability will mitigate the chance that a component failure will stop production.

APPLICATION SECURITY

Installing the InTouch HMI on a computer used as a domain controller is not supported.

Use Application Security to secure your InTouch application, Wonderware Historian, and other sensitive information systems.

Use the $Operator system tag to secure your application. You can then control operator access to specific functions by linking those functions to internal tags.

Use the $Operator system tag to secure your application. Replace the GetNodeName() function with the newer TseGetClientId() function to identify the client computer. When using Terminal Services, the GetNodeName() function returns the name of the terminal server, not the name of the client computer.

SESSION SECURITY

Note: The following information is intended for example purposes ONLY. Your security requirements will differ.

Connection settings and security control not only access to a terminal server through the Terminal Services Client, but also how a user can interact with other users on the server. Connection security is managed through regular Windows 2008 users or groups.

Wonderware recommends that you never control client connection access through individual user accounts even when dealing with only a single server. The administrative work required is much greater than the work required for using groups.

Accordingly, the following local groups should be defined (your group names will be different based on your requirements):

Administrators (for example, WW_Admins) ‟ Members of this group will have administrative connectivity rights on the terminal server. They will be able to perform all functions on other sessions including logging off, disconnecting, and resetting any session.

Users (for example, WW_Users) ‟ Members of this group will have only user connectivity access on this server. This is the preferred choice for operators.

Remote Control Users (for example, WW_Users_RC) ‟ Members of this group will have user connectivity access in addition to the ability to



139

Remotely Control other users. This group is optional, and accommodates users who require this privilege, such as support engineers.

To create terminal server local groups 1. Click Start on the Windows Taskbar, point to Administrative Tools, and then

click Server Manager.

The Server Manager dialog box appears.

2. In the Tree, under Configuration, scroll down and open Local Users and

Groups, then right-click the Groups folder.

3. Click New Group.



139

Add the three recommended local groups: Administrators, Users, and Users_RC.

After the local groups have been created, the next step is to configure the connection security for these groups. Use the Remote Desktop Session Host Configuration tool to manage connection settings and security.

To configure connection security

1. Click Start on the Windows Taskbar.



139

2. Click Administrative Tools/Remote Desktop Services, and then click Remote Desktop Session Host Configuration.

The Remote Desktop Session Host Configuration dialog box appears listing all of the created connection types for the terminal server in the middle top pane.



139

3. Double-click RDP-Tcp. The RDP-Tcp Properties dialog box appears.

4. Select all the listed groups except SYSTEM, and then click Remove.

5. Add the three recommended groups mentioned earlier, and assign them the

following permissions:

Group Permissions WW_Admins Full Control WW_Users User Access WW_Users_RC Special Access (User Access + Remote Control)

ASSIGN GROUP PRIVILEGES

To set the privileges for the WW_Users_RC group, begin by assigning it the User Access privileges. 1. Then click Advanced to view the Access Control Settings for RDP-Tcp dialog

box. 2. Select WW_Users_RC and then click Edit. 3. Check the Allow box for Remote Control. 4. Click OK.

USER ACCOUNT MANAGEMENT

Windows 2008 user account options are valid for Terminal Services. Organizational policy should guide you on the appropriate settings for passwords, time restrictions and auditing.

To configure users to access a terminal server



139

1. Click Start on the Windows Taskbar, then Administrative Tools/Computer Management.

2. In the Tree, open Users folder under Local Users and Groups.

3. Double-click a desired user to open the user’s Properties dialog box.

4. Click the Member Of tab to activate the Member of property sheet.

5. Remove any default groups and add both the appropriate Wonderware group and the Power Users group.



139



139

SECURING THE RDP CONNECTION

You can use the properties of the RDP-Tcp connection to modify both Security layer and encryption level for the RDP connection.

SECURITY LAYER

All RDP connections are encrypted automatically. Security layer settings determine the type of encryption used for these Terminal Services connections. Three options for the security level are available: RDP Security Layer, SSL (TLS 1.0), and Negotiate.

The RDP Security Layer option limits encryption to the native encryption built into Remote Desktop protocol. The advantages of this option are that it requires no additional configuration and that it offers a high standard of performance. Its disadvantage is that it does not provide terminal server authentication for all client types.

Although RDP 6.0 can provide server authentication for clients running Windows Vista and later, Terminal Services clients running Windows XP and earlier do not support server authentication. If you want to enable RDP clients running Windows XP to authenticate the terminal server before establishing a connection, you have to configure SSL encryption.



139

The SSL (TSL 1.0) option offers two advantages over RDP encryption. First, it offers stronger encryption. Second, it offers the possibility of server authentication for RDP client versions earlier than 6.0. SSL is, therefore, a good option if you need to support terminal server authentication for Windows XP clients.

However, this option does have some drawbacks. To begin with, SSL requires a computer certificate for both encryption and authentication. By default, only a self-signed certificate is used, which is equivalent to no authentication. To improve security, you must obtain a valid computer certificate from a trusted certification authority (CA), and you must store this certificate in the computer account certificate store on the terminal server. Another disadvantage of SSL is that its high encryption results in slower performance compared to that of other RDP connections.

When you choose the Negotiate option, the terminal server will use SSL security only when supported by both the client and the server. Otherwise, native RDP encryption is used. Negotiate is also the default selection.

ENCRYPTION LEVEL

The Encryption Level setting on the General tab enables you to define the strength of the encryption algorithm used in RDP connections. The default selection is Client Compatible, which chooses the maximum key strength supported by the client computer. The other available options are FIPS Compliant (highest), High, and Low.



139

NETWORK LEVEL AUTHENTICATION

When the Allow Connections Only From Computers Running Remote Desktop With Network Level Authentication setting is enabled, only clients that support NLA will be allowed to connect to the terminal server.

To determine whether a computer is running a version of the Remote Desktop Connection (RDC) client that supports NLA, start the RDC client, click the icon in the upper-left corner of the Remote Desktop Connection dialog box, and then click About. Look for the phrase Network Level Authentication Supported in the About Remote Desktop Connection dialog box.

DISABLE THE ABILITY TO SWITCH USERS THROUGH THE GROUP POLICY INTERFACE

First, this could be a security policy requirement. A security requirement might be that a user should completely quit all applications and log off from the computer after finishing his or her work on the computer.

By disabling the fast user switching feature, you hide the Switch user button in the Logon user interface, in the Start menu, and in the Task Manager.

Another reason could be performance issues. The fast user switching feature uses some system resources which can be freed in case the fast user switching functionality is not needed.



139

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

1. Click Start/Run.

2. In the Run dialog box, type gpedit.msc.

3. Click OK. The Group Policy dialog box appears.

4. Go to Local Computer Policy > Administrative Templates > System > Logon.

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



139

6. On the File menu, click Exit to close the Group Policy editor.

Important: 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/Run.

2. In the Run dialog box, type regedit.exe.

3. Click OK. The Registry Editor dialog box appears.

4. Go to HKEY_LOCAL_MACHINE > SOFTWARE > Policies > Microsoft > Windows > CurrentVersion > Policies > System.

5. Right-click and select DWORD (32-bit) Value.

6. Name it HideFastUserSwitching.

7. Set the HideFastUserSwitching data value to 1.

8. On the File menu, click Exit to close the Registry Editor.

NEW WINDOWS SERVER 2008 R2 SECURITY FEATURES

Windows Server 2008 R2 has a new security features you should be aware of to guarantee that your InTouch application will work properly.



139

APPLOCKER

AppLocker is used to apply rules specify which files are allowed to run. Make sure that there are not any rules applied against the InTouch folder.

If an AppLocker rule is applied to the InTouch folder, you will see the following error at startup:



139

NEW FEATURES IN USER ACCOUNT CONTROL

The UAC functionality is improved so that it:

Increases the number of tasks that the standard user can perform, which do not require/prompt for administrator approval.

Allows a user with administrator privileges to configure the UAC experience in the Control Panel.

Provides additional local security policies that enable a local administrator to change the behavior of the UAC messages for local administrators in Admin Approval Mode.

UAC Recommendations

You must disable UAC before installing InTouch.

You can re-enable UAC after installation for use on a Runtime machine.

For InTouch development, UAC must be disabled.

For details on disabling UAC in your environment, type UAC into the WDN Search field.

NEW FEATURES IN WINDOWS SECURITY AUDITING

New Auditing enhancements in Windows Server® 2008 R2 increase the level of detail in security auditing logs and simplify the deployment and management of auditing policies.

Global Object Access Auditing: Enable the computer’s System Access Control List (SACL). Under this the object type can be defined as per file system or registry. Once the list is applied it is applied to every object of type you can configure. It is best recommended to track system files. It is recommended for a wide network. It can track changes done to system files and registry.

Reason for access reporting: This list is also called Access Control Entries. The admin can allow privileges to objects. They can allow or deny rights to objects in the environment.

Advanced Audit Policy Settings: 53 new settings are available. The new settings allow the admins to target more specific activities.

https://wdn.wonderware.com/

https://wdn.wonderware.com/



139

USING AUDITING

There are two ways to use it. First you can describe policies which will track the user activities and other system-wide activities.

User actives collect logs of user logins, logouts, file modifications, deletion, etc.

System-wide activities can generate logs on objects’ activities.

Example: User Membership Process

User Membership Process allows you to track

The action that was performed.

The user who performed the action.

The success or failure of the event and the time that the event occurred.

Use security auditing to monitor intrusion attempts. If you suspect that your system is under any sort of attack, you can enable logging for an array of auditable events.

By default, security logging/auditing is disabled because it usually requires excessive processing resources.



139

I/O IN A TERMINAL SERVICES ENVIRONMENT

Note: The use of the term I/O Server in this context can refer to several different things:

DAServers

Legacy I/O Servers (no longer supported by Wonderware)

3rd party I/O Servers

Generic term for applications or programs that communicate to devices.

The InTouch HMI does not start I/O Servers in a Terminal Services environment. Depending on the sequence that View sessions start, you might need to use the IOReinitialize() function. All servers (I/O devices or View applications) must be running before starting an application that reads values from these servers.

Tip: To avoid receiving an Initializing I/O error message when WindowViewer starts, clear (de-select) the Start Local Servers check box on the General tab of the WindowViewer Properties dialog box.

Note: Running WindowViewer as a Windows Service is not a supported configuration because of the Terminal Services architecture.

INTRODUCTION

A PC running the I/O Server, OPC Server, or DAServer is the data source for a System Platform solution. This PC is referred to as the I/O Server node.

I/O Server applications translate data from protocols like DDE, SuiteLink or OPC, into vendor-specific protocols to communicate with controllers, PLCs, or RTUs.


Rev. 1.0 Client Page 100

of 139

In their basic role, I/O Servers maintain the list of items that client applications request, then poll or handle data received from field devices, and pass it to subscribed clients.

I/O SERVERS IN A TSE ENVIRONMENT

Under TSE:

The I/O Servers usually run in the console mode under the default system account (unless you specify which user account to run).

If the server is running as SuiteLink server, all the client applications should be able to access the I/O server in the "remote" mode (client session).

The I/O server will not be able to provide data using the DDE protocol in TSE environment.

WHAT HAPPENS WHEN WINDOWVIEWER OPENS

When WindowViewer is a client and requires the value of an item, it automatically processes an initiate request to start all I/O conversations and requests the item’s value.

The server reports the value and updates WindowViewer only if a change occurs.

All WindowViewer data requests provide information relating an item to a register, coil number, or I/O data point understood by the server.

The server uses the information to automatically handle all messages to and from I/O, hardware devices (PLCs), and/or other data sources.

If an I/O Server program does not respond to WindowViewer's initiate request, you can force WindowViewer to try to re-establish the I/O conversation.

To start all uninitiated I/O conversations:

On the Special menu, click Start Uninitiated Conversations.

Note: Executing this command does not affect existing conversations.

To restart all I/O conversations:

On the Special menu, click Reinitialize I/O.

Note: This command closes all existing I/O conversations and restarts the entire process of setting up I/O conversations. All I/O points are affected by this command.



of 139

The user account used to access and set up the I/O Server on the Terminal Server station is the only user account that can configure the I/O Server, even if the user accessed it from a remote session.

I/O SERVERS ON A SEPARATE NODE

Wonderware recommends running I/O Servers on a designated computer. I/O Servers require a stable system environment (CPU and memory resources).

Running I/O Servers on a separate computer ensures that all resources will be available for the servers without other software interference.

Additionally, when using OPC protocol, Wonderware recommends deploying the OPC Client object to the OPC Server Node. This implementation provides communications stability.

If the OPC Server and the OPC Client are remotely located on different nodes of a network, the Distributed Communication security and authentication configuration and overhead are much more complicated.

In the TSE environment, monitor the I/O Server computer for the following:

Available resources

What other software and utilities are running in that host machine

Protocol requirement (SuiteLink, DDE, or OPC).

EXECUTING SCRIPTS IN A TERMINAL SERVICES ENVIRONMENT

Because all applications running in Terminal Services use a single timing reference (server clock), scripts might not run as designed during periods of excessive CPU loading.

Abnormal CPU loading can be caused by excessive video processing (from Terminal Server session client graphics), or when several applications have the same script triggers defined (such as an End-of-Shift event).



of 139

It is possible that if the server is busy processing scripts from many clients, it may not start a script on another client during the interval when the timer would normally start the script. This condition can prevent the script from running on the client.

To ensure scripts run correctly, combine scripts with common triggers and move them to a single application, such as a tag server.

The difference between scripts that run on TSE and scripts that run on a "normal" application is that in the "normal" application, one client can trigger many scripts at the same time, but in TSE the same script can be triggered by many clients at the same time. The server handles the script execution order according to the server clock.



of 139

In a Terminal Server application, each session is independent of the other sessions. This means that if each session opens the same window of the same InTouch application and changes the value of a slider linked to a Memory tag, each session will see a different value for the same Memory tag. In other words, each session has its own instance of the same Memory tag.



of 139

CREATING A TAG SERVER APPLICATION

By creating an application that contains only InTouch QuickScripts and tagnames, you can establish an instance of WindowViewer that functions as a tag server. You can create another application that contains only windows (and memory tagnames for window logic processing). If these windows contain only remote tagname references, this application can serve as a repository for all the process windows for a facility. In this case, the remote tagname references are tagname references to other WindowViewer instances that function as tag servers.

An instance of WindowViewer that connects to this database functions as an Operator Workstation. This WindowViewer instance can open any window and view data from anywhere on the plant floor.



of 139

For example:

Application DatabaseContains tagnames and quick scripts for system “1”

Application DatabaseContains tagnames and quick scripts for system “2”

I/O ServerWindow Viewer

I/O Server

Operator Workstation

Application DatabaseContains windows with references to remote tagnames

Window Viewer



of 139

ALARMS IN A TERMINAL SERVICES ENVIRONMENT

By using the Distributed Alarm System with InTouch for Terminal Services, your Alarm clients running on different terminal sessions can select what alarm to show and how to present it.

Alarm information is made available to the Distributed Alarm System when the Alarm Provider or the Alarm Consumer registers with the Distributed Alarm System. Registering occurs when the Alarm Provider or Alarm Consumer application starts.

Alarm Providers identify themselves by a unique name that identifies their application, and the application instance. The node on which an Alarm Provider is running is identified by the name of the computer.

When an alarm event is logged, the node and complete Alarm Provider name identify the alarm source.

When an alarm is acknowledged, the Operator Node that gets recorded is the name of the client computer running the Operator's Terminal Services session. If the node name of the computer cannot be retrieved, its IP address is used instead.

Note: Alarm Providers are not supported on Terminal sessions. They are only supported on the Terminal Console.

The Wonderware InTouch Distributed Alarm system includes the Alarm DB Logger utility that logs alarms and events to an alarm database. The Wonderware Alarm DB Logger Manager uses fixed accounts in the Microsoft SQL Server database to access the data.

Note: The DB Logger needs to have a write-access account which you specify using the Alarm DB Logger manager utility.

For Vista, Windows 7 and Windows Server 2008 R2 operating systems, source alarms are not visible to InTouch alarm clients unless the client AlarmViewer query is configured according to the following steps.

The following section applies to Vista, Windows 7, or Windows Server 2008 R2.



of 139

1. After launching InTouch WindowViewer (alarm provider), 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 IP address is unique to your alarm provider node. Note the IP address and use it in the next step.

2. In the Alarm Query tab of the AlarmViewer control on the remote machine, configure the alarm query as follows, substituting your actual node name 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 and verify that the alarms sourced from the alarm provider display correctly in the InTouch AlarmViewer control.



of 139

APPENDIX 1: RETRIEVING INFORMATION ABOUT THE INTOUCH

CLIENT SESSION USING SCRIPTS

You can use the following InTouch QuickScript functions for Terminal Services.

„ TseGetClientId()

„ TseGetClientNodeName()

„ TseQueryRunningOnConsole()

„ TseQueryRunningOnClient()

TseGetClientId() Function

Returns a string version of the client ID (the TCP/IP address of the client) if the View application is running on a Terminal Server client. This client ID is used internally to generate SuiteLink server names and logger file names. Otherwise, the TseGetClientId() function returns an empty string.

Syntax

MessageResult=TseGetClientId();

Example

The client IP address 10.103.202.1 is saved to the MsgTag tag.

MsgTag=TseGetClientID();

TseGetClientNodeName() Function

Returns the client node name if the View application is running on a Terminal Server client assigned a name that can be identified by Windows. Otherwise, the TseGetClientNodeName() function returns an empty string.

Syntax

MessageResult=TseGetClientNodeName();

Example

The client node name is returned as the value assigned to the MsgTag tag.

MsgTag=TseGetClientNodeName();

TseQueryRunningOnConsole() Function

The TseQueryRunningOnConsole() function can be run from a script to indicate whether the View application is running on a Terminal Services console.



of 139

Syntax

Result=TseQueryRunningOnConsole();

Return Value

Returns a non-zero integer value if the View application is running on a Terminal Services console. Otherwise, the TseQueryRunningOnConsole() function returns a zero.

Example

IntTag is set to 1 if WindowViewer is running on a Terminal Services console.

IntTag=TseQueryRunningOnConsole();

TseQueryRunningOnClient() Function

Returns a non-zero integer value if the View application is running on a Terminal Services client. Otherwise, it returns a zero.

Syntax

Result=TseQueryRunningOnClient();

Return Value

Returns 0 if View is not running on a Terminal Services client.

Example

IntTag is set to 1 if WindowViewer is running on a Terminal Services client.

IntTag=TseQueryRunningOnClient;



of 139

APPENDIX 2: TECH NOTE 538 INTOUCH© TSE VERSION 10.0

APPLICATION CONFIGURATION: MANAGED, PUBLISHED AND

STANDALONE METHODS

Topic#: 002275 Created: April 2008

INTRODUCTION

This Tech Note explains setting up InTouch 10.0 in a Terminal Services environment. It covers the three primary application configurations for Managed, Published and Standalone Applications. The three methods of running InTouch from TSE:

Managed Applications: An application which is created, edited and managed in the IDE and deployed to a platform with a view engine. Managed Applications can access galaxy data as well as tag data and can contain ArchestrA Graphics. This is the recommended method for running an InTouch for Terminal Services environment in version 10.x.

Published Applications: Traditional InTouch for Terminal Services configuration, but are created and managed using the IDE and can include ArchestrA Graphic Symbols. Published applications are Published, not Deployed, and the client nodes running the published application do not require an Application Server Platform.

Standalone Applications: Traditional InTouch for Terminal Services configuration created using Wonderware WindowMaker. These are tag-based applications, contain no ArchestrA Graphic Symbols, and are not Deployed. Client nodes running a Standalone application do not require an Application Server Platform.

APPLICATION VERSION

InTouch 10.0

MANAGED APPLICATIONS

This section explains creating, editing, and deploying a managed InTouch application.



of 139

CREATING AN INTOUCH FOR TERMINAL SERVICES MANAGED APPLICATION ENVIRONMENT

WITH APPLICATION SERVER 3.0 AND INTOUCH 10.0

1. In the IDE, create an instance of the $InTouchViewApp Derived Template.

Edits to the application are made to the InTouchViewApp template. We recommend using security to prevent ending up with one user having multiple IDEs open.

2. Assign your new InTouchViewApp object to an Instance of the $ViewEngine System object which must be assigned to a Platform.

3. Deploy the ViewEngine and InTouchViewApp objects with or to a deployed Platform. If you have multiple InTouchViewApp objects, we recommend using one engine for all InTouchViewApp objects, unless there are engine parameters requirements for particular InTouchViewApp objects.

Figure 1: InTouchViewApp Deployment If you make edits once the object is deployed, the instances are marked for pending changes. TSE Session copies will obtain updates depending on how their Change Mode is configured. Configure the Change Mode in WindowMaker™ within the InTouchViewApp template under Special/Configure/WindowViewer on the Managed Applications tab (Figure 2 below). Instances cannot be undeployed if View is running.



of 139

Figure 2: Managed Application Properties in WindowViewer

4. Deploy the instance of the application to a Terminal Server platform

which has InTouch for Terminal Server installed. Terminal Server clients can then run the application within InTouch for Terminal Services. The application directories for each user are automatically created based on the Local working directory in the Managed Application tab under Special/Configure/WindowViewer as shown above. For more information on file locations review Managed Applications Local Working File Locations under the Managed Applications File Locations section below.

Figure 3: Application Manager Showing Managed Applications

Note: Do not use NAD when using the Managed Application method as it is not needed nor intended to work in Managed Applications.



of 139

MANAGED APPLICATIONS FILE LOCATIONS

The Managed Application includes the following file groups: Edit Files Deploy Files Working Files Executed From the Console Files

MANAGED APPLICATION: EDIT FILE LOCATIONS

The storage location of the application while it is edited in the IDE is: C:\Program

Files\ArchestrA\Framework\FileRepository\YourGalaxyName\Obj

ectFileStorage\$YourInTouchViewAppTemplate

The $InTouchViewAppTemplate folder contains three subdirectories: CheckedIn, CheckedOut, Deployed_###. These three folders contain a copy of the InTouch application files structure. Only the CheckedOut folder can be edited manually. In case you need to add application dependency files, edit the InTouch.ini, or recompile. When the application is being edited in WindowMaker, the changes are made to the CheckedOut folder. Once the changes are made and the user exits WindowMaker and checks-in the application, the CheckedIn folder is updated with the changes. Note: Any changes made manually to the CheckedIn folder may be lost and can cause application corruption. One or more Deployed_### folders contain a copy of the last version that was deployed for a particular application. This is for the purpose of redeploy original function.



of 139

Figure 4: Directory Structure for Managed Applications

We recommend using security to prevent ending up with one user having multiple IDEs open.

MANAGED APPLICATION: DEPLOYED FILE LOCATIONS

For each Platform that is going to run this specific InTouch application, an instance of the $InTouchViewAppTemplate template must be created. As an illustration, the example below shows the MillionIOTest_001 on one platform and MillionIOTest_002 on a different platform from Deployment view.



of 139

Figure 5: Deployed File Locations on Different Platforms, From IDE The deployed application is stored in the following directory, on the destination Platform: C:\Program Files\ArchestrA\Framework\Bin\<GalaxyName>-

<ViewAppInstance>

Figure 6: Deployed Files Location in Windows Explorer

Launch the InTouch Application Manager on the platform where you have deployed the InTouchViewApp object. The Managed Application will be automatically listed.



of 139

Figure 7: Managed Application in Application Manager Note: The deployed (source) folder location is NOT the local working directory. The next section explains the local working directory and NAD.

MANAGED APPLICATION: LOCAL WORKING DIRECTORY FILE LOCATIONS

A new setting exists that defines the local working directory of the Managed Application on the destination platform machine. It is in WindowMaker within the IDE under Special/Configure/WindowViewer. The working directory appears on the Managed Application tab. The Local Working directory setting is used as the dynamic path utilized by InTouch when it launches from the client session. This is the case whether WindowViewer™ is launched from the console or from a Terminal Session. The path specified here (Figure 8 below) is dynamically created when the application is launched.



of 139

Figure 8: Dynamic Application Path

IMPORTANT: The NAD settings under the node properties in the InTouch application manager are NOT used for Managed Applications. Even if NAD is enabled, the NAD settings from the node properties are ignored. The application will be copied to and executed from the path configured here (…\ArchestrA\ManagedApp).



of 139

MANAGED APPLICATION: FILE LOCATIONS WHEN EXECUTED FROM THE

CONSOLE

In an operating system such as Windows XP, where the applications are executed from the console, the local working directory is not the one seen in the path of the InTouch Application Manager.

Figure 9: Working Directory from XP

The source path shown above is the source path for the application. Once WindowViewer is launched the application actually executes from: %ITAPPDATA%\ArchestrA\ManagedApp <which is equal to>

C:\Documents and Settings\All Users\Application

Data\ArchestrA\ManagedApp



of 139

Figure 10: Managed Application Path from XP Console

The Managed Application is executed from a Terminal Session opened by User1. A terminal session launched against an operating system such as Windows 2003 will launch the WindowViewer session in the working directory for the logged in user. If User1 is logged in to the terminal session, the local working directory for the session will be: C:\Documents and Settings\User1\Application

Data\ArchestrA\ManagedApp



of 139

Figure 11: Managed Application with User1 Logon

Note: Do not use NAD when using the Managed Application method as it is not needed nor intended to work in Managed Applications.



of 139

PUBLISHED APPLICATIONS

To Create a Published InTouch Application

1. In the IDE, create an instance of the $InTouchViewApp Derived Template. Edits to the application are made to the View Application template.

2. Publish the application to create a non-managed application containing ArchestrA Graphics by right-clicking the $InTouchViewApp template and selecting Publish InTouch Application (Figures 12 and 13 below).

Figure 11: Publish InTouch Application



of 139

Figure 12: Publish Application Complete 4. Run the application as a Standalone NAD Client on the Terminal

Sessions. See the following sections for more information on NAD. Use security to prevent one user having multiple IDEs open.

Note: Published applications cannot be re-imported into a Managed Application template. Changes to published applications must be made to the master application in the IDE and then re-published.



of 139

STANDALONE APPLICATIONS

Create a Standalone InTouch Application with WindowMaker and run the application using NAD (Network Application Development). This is the same method recommended by Wonderware in previous versions. 1. In the InTouch Application Manager, create a new application. Edit the

application in WindowMaker. 2. Run the application as a NAD Client on the Terminal Sessions. Configure

NAD settings in the InTouch Application Manager under Node Properties.

Figure 13: Node Properties Configuration

See the following list of references for more information on NAD Applications. Note: NAD is intended for use with standalone or published applications. Do not use NAD when using the Managed Application method as it is not needed, nor intended to work in Managed Applications.



of 139

APPENDIX 3: INTOUCH LICENSING

USING THE LICENSE UTILITY

To install the InTouch license file

1. Select the License Utility from the Start menu:

The ArchestrA License Manager appears (following figure):



of 139

2. From the File menu click Install License File.

3. Browse to the file's location.

4. Select the license file and then click Open. The license manager shows that

you have successfully installed the license.



of 139

Note: The Log pane shows all log messages associated to a specific license.

The license details are shown when you select the license file.



of 139

INTOUCH 2012 LICENSE FILE

The new License file allows feature lines and “parameters.”

For InTouch 2012 some bit string character sets of existing feature lines are

changed to parameters:

From:

FEATURE InTouch_ Wonderware 10.100 1-jan-00 0

ADC6674A13F9D595E121 \

VENDOR_STRING=03E800000000000300000000 HOSTID=ANY\

To:

FEATURE InTouch Wonderware 10.5 1-jan-00 uncounted \

VENDOR_STRING=ltags:1000; rrefs:1000; mode:3

HOSTID=ANY\

Parameter Description Possible values

ltags: Number Of Local Tags

excluding the system tags.

decimal format

rrefs: Number of remote

references

decimal format

mode: Former

Development/Runtime/

InTouchView application

1 (001) ‟WindowMaker

2 (010) ‟ Fully functional Window Viewer

3 (011) ‟WindowMaker and Fully functional Window

Viewer

6 (110) ‟ WindowViewer with limited functionality

(InTView)

7 (111) ‟ WindowMaker and Limited functionality

WindowViewer

readonly: Read Only 0/1

lang: Enforce language 0/1

windows: Number Of Windows decimal format

rttimeout: Runtime Timeout in minutes decimal format



of 139

iorestrict: IO Restriction Numeric field. For InTouch 10.5 release this can have

value 0/1.

oem: Enforce OEM restrictions Hex number with max value FFFF

InTouch for Terminal Services 2012 Feature line

VENDOR_STRING=count:5

Sample InTouch 2012 License

FEATURE InTouch Wonderware 10.5 1-jan-00 uncounted \

VENDOR_STRING=ltags:61402; rrefs:61402; mode:3 HOSTID=ANY \

FEATURE InTouch_TSE Wonderware 10.5 1-jan-00 uncounted \

VENDOR_STRING=count:5 HOSTID=ANY

INSTALLING THE REMOTE DESKTOP SERVICES LICENSE SERVER

The first step is to install the Remote Desktop Services License Services server role. The license server does not necessarily have to be installed on a system which is acting as a Remote Desktop Server. The installation can be performed using by selecting Roles from the tree in the left-hand panel of the Server Manager tool.

If the server is already configured with the Remote Desktop Services Role

1. Scroll down the Roles Summary page to the Remote Desktop Services section.

2. Click the Add Role Services link.

3. In the Select Role Services dialog box, click Remote Desktop Licensing and then click Next. The Configure Discovery Scope for RD Licensing screen appears:



of 139

In Windows Server 2008, it was necessary to specify a method by which RD Session Host servers (or Terminal Servers as they were known then) would auto-detect the server running the licensing server.

With Windows Server 2008 R2, this approach is discouraged, and Microsoft now recommends that each RD Session Host be manually configured with information about the license server.

4. In keeping with this recommendation, leave the Configure a discovery scope for this license server option unselected. You can change the setting at a later time if required via the RD Licensing Manager tool.

5. Click Next.

On a server which is does not have the Remote Desktop Services role installed

1. Open the Server Manager, click Roles from the tree in the left hand panel and click Add Roles.

2. Click Next if it appears so that the Select Server Roles panel is visible.

3. From the list of roles click Remote Desktop Services and click Next.

4. Read the information screen and then proceed to the Select Service Roles window.

5. Check Remote Desktop Licensing, click Next, and follow the steps outlined above.



of 139

6. On the Confirmation screen, verify that the information matches your expectations and click Install to begin the installation process.

ACTIVATE A LICENSE SERVER

A license server must be activated in order to certify the server and allow it to issue client licenses.

A license server is activated using the licensing wizard, which is located in the Terminal Services Licensing tool. There are four connection methods to activate your license server: Internet, Web, Phone, and Fax.

Internet is the quickest and easiest. All four methods access the Microsoft Clearinghouse, which is a facility to activate license servers and to issue client license key packs to the license servers that request them.

Windows 2008 R2 Server and

Remote Desktop Server

Microsoft Certificate

Authority and License

Clearinghouse

RD Session Host 2

RD Session Host 1

TS Client

TS Client

Mic

rosoft

Plant



of 139

ACTIVATING THE RD LICENSE SERVER

Once the RD License Server has been installed the next task is to activate it.

This task is performed using the RD Licensing Manager.

1. Click Start/All Programs/ Administrative Tools/Remote Desktop Services/Remote Desktop Licensing Manager. The Remote Desktop Licensing Manager dialog appears. It contains a list of detected license servers on the network. The only license server listed in the following figure is the one on the local server. Because it is not activated, it is listed with a red circle containing an X mark next to it (following figure).

2. Connect to https://activate.microsoft.com (using the browser) and provide the product ID. If you do not have an internet connection, or a firewall prevents access, you can activate using the telephone. If Automatic connection is selected, the following dialog will appear as the wizard attempts to contact Microsoft:

3. Once the Microsoft activation server has been located a new dialog box appears prompting for user, company and geographic location information.



of 139

4. Complete these details and click Next to proceed. The second screen requests more detailed, but optional information.

5. Either complete this information or click Next to skip to the activation process. The wizard will contact Microsoft and complete the activation. The following completion wizard appears when activation is complete:

INSTALLING LICENSES

To Install Remote Desktop Services Client Access Licenses (RDS CAL)

You can install Remote Desktop Services client access licenses (RDS CALs) onto your license server in the following ways:

Install Remote Desktop Services Client Access Licenses Automatically

This scenario requires Internet connectivity from the computer running the Remote Desktop Licensing Manager tool.

To install Remote Desktop Services client access licenses automatically, complete the following steps.

1. On the license server, open Remote Desktop Licensing Manager (Start/ Administrative Tools/Remote Desktop Services/Remote Desktop Licensing Manager).

2. Verify that the connection method for the Remote Desktop license server is set to Automatic connection (recommended) by right-clicking the



of 139

license server on which you want to install Remote Desktop Services client access licenses (RDS CALs), and then clicking Properties.

3. On the Connection Method tab, change the connection method if necessary, and then click OK.

4. Right-click the license server on which you want to install the RDS CALs, and then click Install Licenses. The Install Licenses Wizard appears.

5. Click Next.

6. On the License Program page, select the appropriate program through which you purchased your RDS CALs, and click Next.

7. The License Program that you selected on the previous window in the wizard determines what information you need to provide on this window.

In most cases, you must provide either a license code or an agreement number. Consult the documentation provided when you purchased your RDS CALs.



of 139

8. After you have typed the required information, click Next.

9. On the Product Version and License Type page, select the appropriate product version, license type, and quantity of RDS CALs for your environment based on your RDS CAL purchase agreement, and then click Next.



of 139

10. The Microsoft Clearinghouse is automatically contacted and processes your request. The RDS CALs are then automatically installed onto the license server.

11. To complete the process, click Finish. The license server can now issue RDS CALs to clients that connect to a Remote Desktop Session Host (RD Session Host) server.



of 139

INSTALL REMOTE DESKTOP SERVICES CLIENT ACCESS LICENSES BY USING A WEB BROWSER

The Web installation method can be used when the computer running the Remote Desktop Licensing Manager tool does not have Internet connectivity, but you have access to the Web by means of a Web browser from another computer. The URL for the Web installation method is displayed in the Install Licenses Wizard.

INSTALL REMOTE DESKTOP SERVICES CLIENT ACCESS LICENSES BY USING THE TELEPHONE

The telephone installation method allows you to talk to a Microsoft customer service representative to complete the installation process. The appropriate telephone number is determined by the country/region that you chose in the Activate Server Wizard and is displayed by the wizard.



of 139

CLIENT LICENSING

When a client†either a user or a device†connects to an RD Session Host server, the RD Session Host server determines if an RDS CAL is needed. The RD Session Host server then requests an RDS CAL from a Remote Desktop license server on behalf of the client attempting to connect to the RD Session Host server. If an appropriate RDS CAL is available from a license server, the RDS CAL is issued to the client, and the client is able to connect to the RD Session Host server.

Although there is a licensing grace period during which no license server is required, after the grace period ends, clients must have a valid RDS CAL issued by a license server before they can log on to an RD Session Host server.

Microsoft offers a 120-Day Demo License.



of 139

ADDITIONAL RESOURCES

The following Tech Notes are available on the Wonderware Developer Network (login required). Managed Application Tech Notes

511 Wonderware Application Server 3.0 & InTouch® 10.0 System Upgrade and Application/Galaxy Migration Steps

InTouch for Terminal Services Tech Notes

347 InTouch® for Terminal Services: Tips and Tricks 358 InTouch®, Terminal Services, and DHCP

NAD Tech Notes

256 Using Network Application Development (NAD) with InTouch 360 Overcoming NAD-Related Errors 380 InTouch HMI® NAD and Slow Networks: How to Reduce Initial

Startup Time and Network Usage by Preventing the Copy of the Full Application (v7.x and higher)

390 InTouch® NAD and Slow Networks: Reduce Startup Time and Network Bandwidth Consumption by Configuring a NAD Proxy

452 InTouch HMI® NAD: NAD Restart is Slow

https://wdnresource.wonderware.com/support/kbcd/html/1/t002241.htm














of 139

SOURCES

The following sources were used in this document:

INTOUCH® HMI AND ARCHESTRA® INTEGRATION GUIDE

INTOUCH HMI APPLICATION MANAGEMENT AND EXTENSION GUIDE

INTOUCHHMI CONCEPTS AND CAPABILITIES GUIDE

WONDERWARE ARCHESTRA SYSTEM PLATFORM IN A VIRTUALIZED

ENVIRONMENT IMPLEMENTATION GUIDE

TECH NOTE 538 INTOUCH© TSE VERSION 10.0 APPLICATION

CONFIGURATION: MANAGED, PUBLISHED AND STANDALONE METHODS