225 Deployment Guide 225

InTouch_TSE_DG_1.0.
docx
Rev. 1.0
InTouch for Terminal Services

Deployment Guide
Planning and Implementation Guidelines
Revision: 1.0
Copyright 2013, Invensys Systems Inc.
Client
Page 1 of
139
InTouch for Terminal Services Deployment Guide

Rev. 1.0
Client
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
Page 2 of
139

Rev. 1.0
Client
Page 3 of
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

Rev. 1.0
Client
Page 4 of
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

Rev. 1.0
Client
Page 5 of
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

Rev. 1.0
Client
Page 6 of
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)

Rev. 1.0
Client
Page 7 of
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 Users 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/enus/library/cc755053(WS.10).aspx
Remote Desktop Services Overview http://technet.microsoft.com/enus/library/cc725560.aspx
Remote Desktop Services http://technet.microsoft.com/enus/windowsserver/ee236407.aspx
Automation Control Products (ACP) http://www.acpthinclient.com
Note: Adding ACP ThinManager increases the available client types to nonWindows-based workstations, including UNIX, Linux, and industrial display
panels. Consult your vendor to verify Wonderware support for a particular nonWindows-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.

Rev. 1.0
Client
Page 8 of
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).

Rev. 1.0
Client
Page 9 of
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.

Rev. 1.0
Client
Page 10 of
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 terminalservices client session.
For more information, see Chapter 4, Using IDE-Managed InTouch Applications

at Run Time, in the InTouch HMI and ArchestrA Integration Guide.

Rev. 1.0
Client
Page 11 of
139
The following graphic shows the Galaxy and InTouch Development Nodes in
this context:

Rev. 1.0
DEPLOYING THE INTOUCHVIEWAPP OBJECT

ENVIRONMENT
IN A
Client
Page 12 of
139
TERMINAL SERVICES

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.

Rev. 1.0
Client
Page 13 of
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;

Rev. 1.0
Client
Page 14 of
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.

Rev. 1.0
Client
Page 15 of
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
WindowViewer
Supported?
Yes
DDE to an I/O Device or MS

Office (for example, Excel)
No
DDE from MS Office (for

example, Hot-link
configured in Excel)
Historical Trending
Yes
InTouch Alarm DB Logger

MEM OLE Automation
Printing Alarms
Retentive tags
SPC Pro
SQL Access (ODBC)
SuiteLink to an I/O Device
or another InTouch
application.
Yes
No
No
Yes
No
Yes
Yes
Yes
Comment
WindowViewer is not supported running as a
service under Terminal Services.
Use a tag server (console or separate
computer). This includes DDE QuickScripts:
WWExecute(), WWPoke()
and WWRequest().
Excel and the InTouch HMI must be running in
the same session.
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.
---Must use NAD or Managed Application.
Not supported
Database should be on a separate computer.
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.

Rev. 1.0
Client
Page 16 of
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 servercentric 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.
Remote Desktop Services
(Terminal Services)
2008 R2 Environment
InTouch
Application
IO Server
RD Terminal Server
2008 R2
PLC
RDP\ICA protocol is used
to view the InTouch session
RD Gateway
Modem
RD
Se
ces
r vi
ts
Internet
lien
DC
lR
a
n
r
e
Int
External RD Clients
R
08
20

Rev. 1.0
Client
Page 17 of
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.

Rev. 1.0
Session 0
Client
Page 18 of
139
Session 1
Application 1
Service 1
Application 2
Service 2
Application 3
Service 3
Application 4
Application 5
Application 6
Session 2
Application 7
Application 8
Application 9
With Windows Vista, Windows Server 2008, and later versions of Windows,
sessions are assigned as shown in the following figure.

Rev. 1.0
Session 0
Client
Page 19 of
139
Session 1
Service 1
Service 2
Application 1
Application 3
Application 2
Service 3
Session 2
Session 3
Application 4
Application 5
Application 7
Application 6
Application 8
Application 9
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.

Rev. 1.0
Client
Page 20 of
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.

Rev. 1.0
Client
Page 21 of
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.

Rev. 1.0
Client
Page 22 of
139

Terminal Services 2008 R2
RD Broker
Service Installed
InTouch
Application
RD Session Host 1
Terminal Server
2008 R2
RD Web Access
Service Installed
IO Server
RD Web Access
RD Broker
InTouch
Application
RD Session Host
Service Installed
RD Session Host 2
RD
P\I
C
Terminal Server
2008 R2
Ap
rot
o
col
s
s
ve r rver
Ser Se
RD minal 8 R2
r
Te
is u
sed
to
vie
wt
he
RD Gateway
Modem
InT
ou
ch
s
ess
ion
es
vic
Ser 2
RD 008 R
2
RD Gateway
Service Installed
Internet
e
Int
DC
lR
rna
ts
lien
e
Ext
DC
lR
rna
0
20
ts
lien
PLC

Rev. 1.0
Client
Page 23 of
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
(Its 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.

Rev. 1.0
Client
4. Click Next. The Remote Desktop Services wizard appears.
5. Click Next.
Page 24 of
139

Rev. 1.0
Client
Page 25 of
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

Rev. 1.0
Client
Page 26 of
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.

Rev. 1.0
Client
Page 27 of
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 graphicsintensive 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.

Rev. 1.0
Client
Page 28 of
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).

Rev. 1.0
Client
Page 29 of
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.

Rev. 1.0
Client
Page 30 of
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.

Rev. 1.0
Client
Page 31 of
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
3389the port used for Remote Desktop connectionsis 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.

Rev. 1.0
Client
Page 32 of
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.

Rev. 1.0
Client
Page 33 of
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.
Terminal Services for InTouch
Benefits
InTouch
Application
Manage Network
Load Balancing (NLB)
and Availability
RD Session Host 1
Terminal Server
2008 R2
Web Access To
InTouch Applications
IO Server
InTouch
Application
Remote Access To
RD Web Access
Centralized InTouch
Application Management
RD Broker
PLC
RD Session Host 2
Terminal Server
2008 R2
RD
P\I
C
Ap
rot
o
cols
Manage Network Load

Balancing (NLB) and
Availability
is u
sed
to
vie
wt
he
s
ve r rver
Ser Se
RD minal 8 R2
r
Te
0
20
RD Gateway
Modem
InT
ou
ch
s
ess
io
es
vic
Ser 2
RD 008 R
2
n
Internet
e
Int
DC
lR
rna
ts
lien
e
Ext
DC
lR
rna
ts
lien
Note: Wonderware strongly recommends that you consult a Microsoft

professional and perform adequate testing before deploying load balancing into
your production environment.

Rev. 1.0
Client
Page 34 of
139
GETTING STARTED WITH INTOUCH FOR TERMINAL SERVICES

UNDERSTANDING INTOUCH FOR TERMINAL SERVICES
Services enabled.
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.

Rev. 1.0
Client
Page 35 of
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.
Services enabled.
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.
The benefit of using Terminal Services is that it allows you to run multiple,
autonomous InTouch applications simultaneously on a Terminal Server.

Rev. 1.0
Client
Page 36 of
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.

Rev. 1.0
Client
Page 37 of
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.
Terminal Services Environment
Running
Managed InTouch Application
on RD Session Host
Running
Published InTouch Application
on RD Session Host
InTouch
Application
RD Session Host 1
Terminal Server
2008 R2
IO Server
InTouch
Application
RD Web Access
Running
Standalone InTouch
Applications
on RD Session Host
RD Broker
Running InTouch
Viewer
On TS Clients
PLC
RD Session Host 2
Terminal Server
2008 R2
RD
P\I
C
Ap
rot
o
s
ve r rver
Ser Se
RD minal 8 R2
cols
r
Te
is u
sed
to
vie
wt
he
0
20
RD Gateway
Modem
InT
ou
ch
s
ess
io
es
vic
Ser 2
RD 008 R
2
n
Internet
e
Int
ts
lien
DC
lR
rna
e
Ext
DC
lR
rna
ts
lien
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.

Rev. 1.0
Client
Page 38 of
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 Server
Windows 2008 / R2
InTouch
Application
Corporate Network
RD Clients running Remote InTouch App
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

Rev. 1.0
Client
Page 39 of
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
InTouch
Application
ACP
ThinManager
Server
Corporate Network
Thin Clients running Remote InTouch App
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 ThinManagerReady 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.

Rev. 1.0
Client
Page 40 of
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 autocreation, replacement, feature grouping, and downloadable modules for simpler
configuration and greater functionality in a Terminal Services Environment

Rev. 1.0
PLANNING
CONSIDERATIONS
APPLICATIONS
FOR
Client
TERMINAL
Page 41 of
139
SERVER
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

Rev. 1.0
Client
Page 42 of
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.

Rev. 1.0
Client
Page 43 of
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 loadbalanced 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
users 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.

Rev. 1.0
Client
Page 44 of
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):
InTouch Node
Domain Network
Client Machine
Client Machine
Client Machine
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.

Rev. 1.0
Page 45 of
139
Client
The following figure displays a topology with Networking Load Balancing:

Domain Network
NLB Cluster
InTouch
Node
InTouch
Node
Remote Session Broker

Node
Domain Network
Client Machine
Client Machine
Client Machine
Connects to the NLB Cluster Node via Remote Desktop
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.

Rev. 1.0
Client
Page 46 of
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.

Rev. 1.0
Client
Page 47 of
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
NLB Cluster
InTouch
Node
InTouch
Node
Domain Network
Client Machine
Client Machine
Client Machine

Rev. 1.0
Client
Page 48 of
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.

Rev. 1.0
Page 49 of
139
Client
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
NLB Cluster
InTouch
Node
InTouch
Node
Remote Session Broker

Node
Domain Network
Client Machine
Client Machine
Client Machine

Rev. 1.0
Client
Page 50 of
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
3. Create a Network Load Balancing Cluster. For more information, refer to
"Creating a Network Load Balancing Cluster" in the ArchestrA System
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
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

Rev. 1.0
Client
Page 51 of
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.

Rev. 1.0
Client
Page 52 of
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.

Rev. 1.0
Client
Page 53 of
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.

Rev. 1.0
Client
Page 54 of
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.

Rev. 1.0
Client
Page 55 of
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.

Rev. 1.0
Client
Page 56 of
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).

Rev. 1.0
Client
Page 57 of
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.

Rev. 1.0
Client
Page 58 of
139
5. Click the Network Load Balancing item, and then click Next. The Confirm
Installation Selections screen appears.
6. Click Install.

Rev. 1.0
Client
Page 59 of
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.

Rev. 1.0
Client
Page 60 of
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.

Rev. 1.0
Client
Page 61 of
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.

Rev. 1.0
Client
Page 62 of
139
The New Cluster : Connect window appears.
4. In the Host box, type the name of the host (node 1), and then click Connect.

Rev. 1.0
Client
Page 63 of
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.

Rev. 1.0
Client
Page 64 of
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.

Rev. 1.0
Client
Page 65 of
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.

Rev. 1.0
Client
Page 66 of
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.

Rev. 1.0
Client
Page 67 of
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.

Rev. 1.0
Client
Page 68 of
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.

Rev. 1.0
Client
Page 69 of
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

Rev. 1.0
Client
Page 70 of
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, doubleclick Member of farm in RD Connection Broker.
The Properties window appears.

Rev. 1.0
4. Click Change Settings.
The RD Connection Broker Settings window appears.
5. Click the Farm member option.
Client
Page 71 of
139

Rev. 1.0
Client
Page 72 of
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.

Rev. 1.0
Client
Page 73 of
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.

Rev. 1.0
Client
Page 74 of
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 newlycreated group.

Rev. 1.0
Client
Page 75 of
139
You can now select the group names in the left pane and view the sessions
connected to each node of the cluster.

Rev. 1.0
Client
Page 76 of
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 (serverbased) 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.

Rev. 1.0
Client
Page 77 of
139
Information about the license Type appears with the license name and license
components when you view it in the ArchestrA License Manager.
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)
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

Rev. 1.0
Page 78 of
139
Client
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.

Rev. 1.0
Client
Page 79 of
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

Rev. 1.0
Client
Page 80 of
139
1
4
InT
o
Se uch
ss
ion RT
Ta 1 TSE
gs 3K
No
3
InT
o
Se uch
ss
ion RT
Ta 1 TSE
gs 3K
InT
o
Se uch
ss
ion RT
Ta 1 TSE
gs 3K
Int
o
at uch
co Se
ns ss
ole ion
08
20 th
s
i
ow w p
nd rver skto
i
W Se D e
R2 ote
m
Re
Cs
PL

Rev. 1.0
Client
Page 81 of
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.

Rev. 1.0
Client
Page 82 of
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 clienteither a user or a deviceconnects 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.

Rev. 1.0
Client
Page 83 of
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

Rev. 1.0
Client
Page 84 of
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

Rev. 1.0
Client
Page 85 of
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.

Rev. 1.0
Client
Page 86 of
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.

Rev. 1.0
Client
Page 87 of
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.

Rev. 1.0
Client
Page 88 of
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
WW_Admins
WW_Users
WW_Users_RC
Permissions
Full Control
User Access
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

Rev. 1.0
Client
Page 89 of
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 users 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.

Rev. 1.0
Client
Page 90 of
139

Rev. 1.0
Client
Page 91 of
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.

Rev. 1.0
Client
Page 92 of
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.

Rev. 1.0
Client
Page 93 of
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.

Rev. 1.0
Client
Page 94 of
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.

Rev. 1.0
Client
Page 95 of
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.

Rev. 1.0
Client
Page 96 of
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:

Rev. 1.0
Client
Page 97 of
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 computers 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.

Rev. 1.0
Client
Page 98 of
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.

Rev. 1.0
Client
Page 99 of
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 items 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.

Rev. 1.0
Client
Page 101
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).

Rev. 1.0
Client
Page 102
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.

Rev. 1.0
Client
Page 103
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.

Rev. 1.0
Client
Page 104
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.

Rev. 1.0
Client
For example:
Application Database
Contains tagnames and quick scripts for system 1 Contains tagnames and quick scripts for system 2
I/O Server
Window Viewer
I/O Server
Window Viewer
Operator Workstation
Contains windows with references to remote tagnames
Page 105
of 139

Rev. 1.0
Client
Page 106
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.

Rev. 1.0
Client
Page 107
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.

Rev. 1.0
Client
Page 108
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.

Rev. 1.0
Client
Page 109
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;

Rev. 1.0
Client
Page 110
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 tagbased 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.

Rev. 1.0
Client
Page 111
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.

Rev. 1.0
Client
Page 112
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.

Rev. 1.0
Client
Page 113
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.

Rev. 1.0
Client
Page 114
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.

Rev. 1.0
Client
Page 115
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.

Rev. 1.0
Client
Page 116
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.

Rev. 1.0
Client
Page 117
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).

Rev. 1.0
MANAGED APPLICATION: FILE LOCATIONS

CONSOLE
WHEN
Page 118
of 139
Client
EXECUTED
FROM THE
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

Rev. 1.0
Client
Page 119
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

Rev. 1.0
Client
Page 120
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.

Rev. 1.0
Client
Page 121
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

Rev. 1.0
Client
Page 122
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.

Rev. 1.0
Client
Page 123
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.

Rev. 1.0
Client
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):
Page 124
of 139

Rev. 1.0
Client
Page 125
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.

Rev. 1.0
Client
Page 126
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.

Rev. 1.0
Client
Page 127
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

Rev. 1.0
Client
Page 128
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:

Rev. 1.0
Client
Page 129
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.

Rev. 1.0
Client
Page 130
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.
Wi
nd
Re ows
mo 20
0
RD
te
D e 8 R2
S
sk
Ho essio
top Serv
st
Se e r a
1 n
rve nd
r
ic
r
os
of
t
lie
nt
S
Ho essio
st
2 n
la
nt
lie
nt
RD
TS
C
TS
C
M
Au icros
tho of
t
Cle rity a Cert
ari nd ific
a
ng
ho Licen te
us
e se

Rev. 1.0
Client
Page 131
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.

Rev. 1.0
Client
Page 132
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

Rev. 1.0
Client
Page 133
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.

Rev. 1.0
Client
Page 134
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.

Rev. 1.0
Client
Page 135
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.

Rev. 1.0
Client
Page 136
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.

Rev. 1.0
Client
Page 137
of 139
CLIENT LICENSING
When a clienteither a user or a deviceconnects 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.

Rev. 1.0
Client
Page 138
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

Rev. 1.0
Client
Page 139
of 139
SOURCES
The following sources were used in this document:
INTOUCH HMI AND ARCHESTRA INTEGRATION G UIDE
INTOUCH HMI A PPLICATION MANAGEMENT AND EXTENSION G UIDE
INTOUCHHMI CONCEPTS AND CAPABILITIES GUIDE
WONDERWARE ARCHESTRA SYSTEM PLATFORM IN A VIRTUALIZED

ENVIRONMENT IMPLEMENTATION GUIDE
TECH NOTE 538 INTOUCH TSE VERSION 10.0 A PPLICATION

CONFIGURATION: MANAGED, PUBLISHED AND STANDALONE METHODS

225 Deployment Guide 225

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

225 Deployment Guide 225

Hochgeladen von

Copyright:

Verfügbare Formate

InTouch_TSE_DG_1.0.

InTouch for Terminal Services

Copyright 2013, Invensys Systems Inc.

InTouch for Terminal Services Deployment Guide

2013 Invensys Systems, Inc. All rights reserved.

No part of the material protected by this copyright may be reproduced or

InTouch for Terminal Services Deployment Guide

InTouch for Terminal Services Deployment Guide

SYSTEM REQUIREMENTS ................................................................................................................................. 41

InTouch for Terminal Services Deployment Guide

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

InTouch for Terminal Services Deployment Guide

AUTHORING AND TESTING:

Alicia Rantos (GCS Lake Forest)

REVIEW AND DISTRIBUTION

Ray Norman (Application Engineering Lake Forest)

InTouch for Terminal Services Deployment Guide

WELCOME TO INTOUCH FOR TERMINAL SERVICES

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

Remote Desktop Services Overview http://technet.microsoft.com/enus/library/cc725560.aspx

Remote Desktop Services http://technet.microsoft.com/enus/windowsserver/ee236407.aspx

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

RDP: Remote Desktop Protocol. The default connection protocol installed

RDS: Remote Desktop Services

Session: A log-on instance where 100 percent of the resources

Terminal Services: A service that enables a server-grade computer for

InTouch for Terminal Services Deployment Guide

Familiar with the Windows 2008 R2 operating system working

Knowledgeable of how to use of a mouse, Windows menus, select

Experienced with a programming or macro language. For best results,

InTouch for Terminal Services Deployment Guide

USING TERMINAL SERVICES

Terminal Services Server: The server manages the computing resources

Remote Desktop Protocol (RDP): A Remote Desktop Protocol (RDP) client

Client: The Terminal Services client performs no local application

InTouch for Terminal Services Deployment Guide

RUNNING A MANAGED INTOUCH APPLICATION WITH TERMINAL SERVICES

In a typical Terminal Services architecture, application development,

For more information, see Chapter 4, Using IDE-Managed InTouch Applications

InTouch for Terminal Services Deployment Guide

InTouch for Terminal Services Deployment Guide

DEPLOYING THE INTOUCHVIEWAPP OBJECT

You can run managed InTouch applications in a Terminal Services environment.

Install InTouch 10.x or later on a computer with Remote Desktop Services

InTouch for Terminal Services Deployment Guide

CONFIGURE HISTORICAL LOGGING ON INTOUCH FOR TERMINAL SERVICES

Configure Historical Logging using the $HistoricalLogging tagname.

Create an Application Startup script using TSEQueryRunningOnClient().

Code Example (from above figure):

InTouch for Terminal Services Deployment Guide

CONFIGURING AUTOMATIC STARTUP

InTouch for Terminal Services Deployment Guide

MISCELLANEOUS LIMITATIONS IN A TERMINAL SERVICES ENVIRONMENT

DDE to an I/O Device or MS

DDE from MS Office (for

InTouch Alarm DB Logger

InTouch for Terminal Services Deployment Guide

INTRODUCTION TO INTOUCH FOR TERMINAL SERVICES

INTOUCH FOR TERMINAL SERVICES

INTOUCH IN THE TERMINAL SERVICES ENVIRONMENT

InTouch for Terminal Services Deployment Guide

WHY WAS TERMINAL SERVICES RENAMED TO REMOTE DESKTOP SERVICES IN WINDOWS

Improved application compatibility guarantees that legacy applications

HOW THE /ADMIN SWITCH BEHAVES