InTouch for Terminal Services Deployment Guide Planning and Implementation Guidelines

Transcription

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

2 Page 2 of 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 Rancho Parkway South Lake Forest, CA

3 Page 3 of 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 Key Points DEPLOYING THE INTOUCHVIEWAPP OBJECT IN A TERMINAL SERVICES ENVIRONMENT CONFIGURE HISTORICAL LOGGING ON INTOUCH FOR TERMINAL SERVICES CONFIGURING AUTOMATIC STARTUP MISCELLANEOUS LIMITATIONS IN A TERMINAL SERVICES ENVIRONMENT INTRODUCTION TO INTOUCH FOR TERMINAL SERVICES INTOUCH FOR TERMINAL SERVICES INTOUCH IN THE TERMINAL SERVICES ENVIRONMENT Why was Terminal Services renamed to Remote Desktop Services In Windows Server 2008 R2? How the /admin switch behaves Remote Desktop Services (Role) Using Remote Desktop Services Remote Desktop Services (Role services) INSTALLING REMOTE DESKTOP SERVICES Install Remote Desktop Services (Role) Install Specific Remote Desktop Services INTOUCH FOR TERMINAL SERVICES Why InTouch for Terminal Services? Terminal Services Benefits for InTouch Remote Control GETTING STARTED WITH INTOUCH FOR TERMINAL SERVICES UNDERSTANDING INTOUCH FOR TERMINAL SERVICES Key Points RUNNING INTOUCH APPLICATIONS IN A TERMINAL SERVICES ENVIRONMENT Standalone InTouch for Terminal Services configuration created using Wonderware WindowMaker Running a Managed InTouch Application with Terminal Services Running a Published InTouch Application with Terminal Services TYPES OF INTOUCH FOR TERMINAL SERVICES WINDOWS 2008/R TERMINAL SERVICES BEHAVIOR IN WINDOWS SERVER ACP THIN MANAGER How ThinManager Works PLANNING CONSIDERATIONS FOR TERMINAL SERVER APPLICATIONS... 41

4 Page 4 of SYSTEM REQUIREMENTS WORKING WITH NETWORK LOAD BALANCING About the Network Load Balancing Feature About Remote Desktop Connection Broker About Managed InTouch Applications with Network Load Balancing SETTING UP A NETWORK LOAD BALANCING CLUSTER Topology 1: Leveraging Network Load Balancing by Configuring Remote Desktop Connection Broker on One of the NLB Cluster Nodes Topology 2: Leveraging Network Load Balancing by Configuring Remote Desktop Connection Broker on a Separate Node INSTALLING REMOTE DESKTOP SERVICES Installing Network Load Balancing Adding a Remote Desktop Session Host Server Creating a Network Load Balancing Cluster CONFIGURING REMOTE DESKTOP CONNECTION BROKER SETTINGS DISCONNECTING FROM AND CONNECTING TO A REMOTE DESKTOP SESSION Viewing Connected Sessions WONDERWARE LICENSING LICENSE TYPES HOW WONDERWARE SOFTWARE USES LICENSES Wonderware CAL ( Access License) When You Need a CAL InTouch Runtime TSE License file Installing the InTouch for Terminal Services License Remote Desktop Licensing PLANNING SECURITY IN A TERMINAL SERVICES ENVIRONMENT DEFINING SECURITY Physical Security Application Security Session Security Assign Group Privileges User Account Management Securing the RDP connection Security Layer ENCRYPTION LEVEL NETWORK LEVEL AUTHENTICATION Disable the ability to switch users through the Group Policy interface NEW WINDOWS SERVER 2008 R2 SECURITY FEATURES AppLocker New features in User Account Control New Features in Windows Security Auditing Using Auditing I/O IN A TERMINAL SERVICES ENVIRONMENT INTRODUCTION I/O SERVERS IN A TSE ENVIRONMENT WHAT HAPPENS WHEN WINDOWVIEWER OPENS I/O SERVERS ON A SEPARATE NODE EXECUTING SCRIPTS IN A TERMINAL SERVICES ENVIRONMENT CREATING A TAG SERVER APPLICATION

5 Page 5 of ALARMS IN A TERMINAL SERVICES ENVIRONMENT APPENDIX 1: RETRIEVING INFORMATION ABOUT THE INTOUCH CLIENT SESSION USING SCRIPTS APPENDIX 2: TECH NOTE 538 INTOUCH TSE VERSION 10.0 APPLICATION CONFIGURATION: MANAGED, PUBLISHED AND STANDALONE METHODS INTRODUCTION Application Version MANAGED APPLICATIONS Creating an InTouch for Terminal Services Managed Application Environment with Application Server 3.0 and InTouch Managed Applications File Locations Managed Application: Edit File Locations MANAGED APPLICATION: DEPLOYED FILE LOCATIONS MANAGED APPLICATION: LOCAL WORKING DIRECTORY FILE LOCATIONS MANAGED APPLICATION: FILE LOCATIONS WHEN EXECUTED FROM THE CONSOLE PUBLISHED APPLICATIONS STANDALONE APPLICATIONS APPENDIX 3: INTOUCH LICENSING USING THE LICENSE UTILITY INTOUCH 2012 LICENSE FILE INSTALLING THE REMOTE DESKTOP SERVICES LICENSE SERVER ACTIVATE A LICENSE SERVER ACTIVATING THE RD LICENSE SERVER INSTALLING LICENSES Install Remote Desktop Services Access Licenses by Using a Web Browser Install Remote Desktop Services Access Licenses by Using the Telephone CLIENT LICENSING ADDITIONAL RESOURCES SOURCES...

6 Page 6 of 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)

7 Page 7 of WELCOME TO INTOUCH FOR TERMINAL SERVICES Before You Begin The InTouch for Terminal Services Deployment Guide is intended to help you efficiently plan, deploy and run InTouch applications on Windows 2008 R2 Remote Desktop Services (formally Terminal Services). As a complement to the InTouch for Terminal Services User s Guide, it provides greater detail in architecture design, hardware selection, and how to leverage the features of Terminal Services in an industrial environment. It specifically addresses the RDP protocol. Additional information on RDP and related protocols are available at the following websites: Microsoft Terminal Services Overview Remote Desktop Services Overview Remote Desktop Services Automation Control Products (ACP) Note: Adding ACP ThinManager increases the available client types to non- Windows-based workstations, including UNIX, Linux, and industrial display panels. Consult your vendor to verify Wonderware support for a particular non- Windows-based operating system. TERMINOLOGY Console: This is the normal desktop experience on the computer that has Terminal Services installed. RDP: Remote Desktop Protocol. The default connection protocol installed with Windows Terminal Services. RDS: Remote Desktop Services Session: A log-on instance where 100 percent of the resources (processing, memory, and hard disk) are managed under a virtual user account, referred to as a Session ID. Terminal Services: A service that enables a server-grade computer for multi-user processing and management.

8 Page 8 of Thin : (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).

9 Page 9 of 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. : 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 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.

10 Page 10 of 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.

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

12 Page 12 of DEPLOYING THE INTOUCHVIEWAPP OBJECT IN A TERMINAL SERVICES ENVIRONMENT You can run managed InTouch applications in a Terminal Services environment. The main advantage of this architecture is that you can run multiple InTouch applications on one computer at the same time. To do this, you must: Install InTouch 10.x or later on a computer with Remote Desktop Services (RDS) installed. Run each managed InTouch application on its own terminal Server Node. Run each InTouch View client in a separate Terminal Services client session. Note: Each Terminal Services client session uses a unique user logon.

13 Page 13 of 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 TSEQueryRunningOn(). Code Example (from above figure): = TseQueryRunningOn(); IF client == 1 THEN IOSAccessName["Tagserver","davidu6","View","Tagname"]; $HistoricalLogging = 0; ENDIF;

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

15 Page 15 of MISCELLANEOUS LIMITATIONS IN A TERMINAL SERVICES ENVIRONMENT The following table describes the limitations and suggested solutions to run applications on a terminal server. Feature Supported? Comment WindowViewer Yes WindowViewer is not supported running as a service under Terminal Services. DDE to an I/O Device or MS Office (for example, Excel) DDE from MS Office (for example, Hot-link configured in Excel) No Yes 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. Historical Trending Yes Use a tag server or NAD to log values. Multiple sessions may read the same historical files, but only a console can write to historical files. InTouch Alarm DB Logger Yes -- MEM OLE Automation No -- Printing Alarms No -- Retentive tags Yes Must use NAD or Managed Application. SPC Pro No Not supported SQL Access (ODBC) Yes Database should be on a separate computer. SuiteLink to an I/O Device or another InTouch application. Yes When communicating to another view session, include the Terminal Server node name and append the IP address of the desired session to the application name. For example, view I/O Servers are not supported in client sessions..

16 Page 16 of 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 PLCs RDP\ICA protocol is used to view the InTouch session RD Gateway Modem RD Services 2008 R2 Internal RD s Internet External RD s

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

18 Page 18 of Session 0 Session 1 Application 1 Service 1 Application 4 Application 2 Service 2 Application 5 Application 6 Application 3 Service 3 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.

19 Page 19 of Session 0 Session 1 Service 1 Service 2 Application 1 Service 3 Application 2 Application 3 Session 2 Session 3 Application 4 Application 7 Application 5 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.

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

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

22 Page 22 of Remote Desktop Services Terminal Services 2008 R2 RD Broker Service Installed InTouch Application RD Web Access Service Installed RD Session Host 1 Terminal Server 2008 R2 IO Server RD Web Access RDP\ICA protocols is used to view the InTouch session RD Broker InTouch Application RD Session Host 2 Terminal Server 2008 R2 RD Session Host Service Installed RD Servers Terminal Server 2008 R2 PLCs Modem RD Gateway RD Services 2008 R2 RD Gateway Service Installed Internet Internal RD s External RD s

23 Page 23 of INSTALLING REMOTE DESKTOP SERVICES Installing Remote Desktop Services is accomplished by completing the following tasks: INSTALL REMOTE DESKTOP SERVICES (ROLE) 1. To begin the installation, click Start/Administrative Tools/Server Manager (It s assumed that a dedicated Windows 2008 R2 server has been setup). 2. Click Roles in the left navigation pane and then click Add Roles in the right pane. The Add Roles Wizard appears. 3. Click Next, then click Remote Desktop Services as the role to install on this server.

24 Page 24 of 4. Click Next. The Remote Desktop Services wizard appears. 5. Click Next.

25 Page 25 of 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

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

27 Page 27 of 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.

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

29 Page 29 of 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 s (RDP ) 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.

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

31 Page 31 of Internet Access Using Microsoft's new RD Gateway (introduced in Windows Server 2008), remote users can access a terminal server over the Internet. A Remote Desktop Gateway (RD Gateway) server is a type of gateway that enables authorized users to connect to remote computers on a corporate network from any computer with an Internet connection. RD Gateway is based on the RDP feature set. RD Gateway uses the Remote Desktop Protocol (RDP) along with the HTTPS protocol to help create a secure, encrypted connection. In earlier versions of Remote Desktop Connection, people couldn't connect to remote computers across firewalls and network address translators because port 3389 the port used for Remote Desktop connections is typically blocked to enhance network security. However, an RD Gateway server uses port 443, which transmits data through a Secure Sockets Layer (SSL) tunnel. The RD Gateway server provides these benefits: Enables Remote Desktop connections to a corporate network from the Internet without having to set up virtual private network (VPN) connections. Enables connections to remote computers across firewalls. Allows you to share a network connection with other programs running on your computer. This enables you to use your ISP connection instead of your corporate network to send and receive data over the remote connection. You can therefore support real-time monitoring and control for their mobile operators with either the Terminal Services software or by simply launching a web browser and connecting to remote computers on a corporate network, from any computer with an Internet connection.

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

33 Page 33 of 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 Manage Network Load Balancing (NLB) and Availability RD Session Host 1 Terminal Server 2008 R2 InTouch Application Web Access To InTouch Applications Remote Access To InTouch Applications RD Web Access RD Broker IO Server InTouch Application Centralized InTouch Application Management PLCs Manage Network Load Balancing (NLB) and Availability RD Session Host 2 Terminal Server 2008 R2 RD Servers Terminal Server 2008 R2 RDP\ICA protocols is used to view the InTouch session Modem RD Gateway RD Services 2008 R2 Internet Internal RD s External RD s Note: Wonderware strongly recommends that you consult a Microsoft professional and perform adequate testing before deploying load balancing into your production environment.

34 Page 34 of GETTING STARTED WITH INTOUCH FOR TERMINAL SERVICES UNDERSTANDING 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. 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.

35 Page 35 of 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. nodes running a Standalone application do not require an Application Server Platform. 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. We highly recommend the use of Network Application Distribution (NAD) when running standalone InTouch applications in a Terminal Services environment. Note: Configure NAD in Node Properties for each user that connects to InTouch for Terminal Services. RUNNING A MANAGED INTOUCH APPLICATION WITH TERMINAL SERVICES A Managed InTouch Application is an application that is created, edited and managed in the IDE and deployed to a Platform with a View Engine. Managed Applications can access Galaxy data as well as tag data and can contain ArchestrA Graphics. This is the recommended method for running an InTouch for Terminal Services environment in version 10.x. You can run managed InTouch applications in a Terminal Services environment. The benefit of using Terminal Services is that it allows you to run multiple, autonomous InTouch applications simultaneously on a Terminal Server.

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

37 Page 37 of 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. InTouch Applications Terminal Services Environment Running Managed InTouch Application on RD Session Host InTouch Application Running Published InTouch Application on RD Session Host RD Session Host 1 Terminal Server 2008 R2 IO Server InTouch Application Running Standalone InTouch Applications on RD Session Host Running InTouch Viewer On TS s RD Web Access RD Broker ` RD Session Host 2 Terminal Server 2008 R2 PLCs RD Servers Terminal Server 2008 R2 RDP\ICA protocols is used to view the InTouch session Modem RD Gateway RD Services 2008 R2 Internet Internal RD s External RD s 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 s 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.

38 Page 38 of 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 Remote Desktop Services Windows 2008 / R2 InTouch Application Corporate Network RD s 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

39 Page 39 of 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 Corporate Network ACP ThinManager Server Thin s 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 ThinManager- Ready Thin s and Terminal Servers. Because ThinManager is a Thin enabling technology, each connected ThinManager-Ready Thin device is guaranteed to have the same internal software, assuring uniformity of operation across a wide variety of models.

40 Page 40 of HOW THINMANAGER WORKS Display s 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 s with a single thin client. Using session tiling you can even view up to 25 Display s on a single monitor. TermSecure extends this functionality even more by allowing you to link Display s 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

41 Page 41 of PLANNING CONSIDERATIONS FOR TERMINAL SERVER APPLICATIONS SYSTEM REQUIREMENTS The following system specifications are supported. The following information was derived from the specific test plan and is not intended as a limitation. TSE Platforms (10 Platforms) Hardware: 2.8 GHz with 2 GB RAM, 1 GB network switch Software: Distributed (refer to the following graphic) Windows Server 2003 SP2 (32 and 64-bit version) Windows 7 and SP1 Windows Server 2008 R2 and SP1 In Wonderware tests, the TSE Platforms were used for client connection only. The Platforms did not have App Engines. Each Platform was configured to be an alarm provider and was filtered to subscribe to eleven Areas. Each Platform was deployed to a Terminal Services machine. The ten Platforms serviced ten client connections each. Nodes (10 Nodes with 100 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

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

43 Page 43 of 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 user s session resides. Remote Desktop Connection Broker is also used to provide users with access to RemoteApp and Desktop Connection. RemoteApp and Desktop Connection provide a customized view of RemoteApp programs and virtual desktops. Remote Desktop Connection Broker supports load balancing and reconnection to existing sessions on virtual desktops accessed by using RemoteApp and Desktop Connection. To configure the Remote Desktop Connection Broker server to support RemoteApp and Desktop Connection, use the Remote Desktop Connection Manager tool. For more information, see the Remote Desktop Connection Manager Help in Windows Server 2008 R2. Remote Desktop Connection Broker that is used in an NLB setup is included in Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise and Windows 2008 R2 Datacenter. The NLB feature is included in Windows Server 2008 R2. You do not require a license to use this feature.

44 Page 44 of 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 Machine Machine 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.

45 Page 45 of The following figure displays a topology with Networking Load Balancing: Domain Network NLB Cluster InTouch Node InTouch Node Remote Session Broker Node Domain Network Machine Machine 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.

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

47 Page 47 of 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 Machine Machine Machine Connects to the NLB Cluster Node via Remote Desktop

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

49 Page 49 of 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 Machine Machine Machine Connects to the NLB Cluster Node via Remote Desktop

50 Page 50 of To configure NLB with Topology 2 On the NLB Cluster nodes, do the following: 1. Install Remote Desktop Services. For more information refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN. Note: In the Select Role Services screen, select Remote Desktop Session Host on the NLB Cluster nodes. 2. Install Network Load Balancing. For more information, refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN. 3. Create a Network Load Balancing Cluster. For more information, refer to "Creating a Network Load Balancing Cluster" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN. 4. Configure remote desktop connection broker settings. For more information, refer to "Configuring Remote Desktop Connection Broker Settings" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN. On the Remote Desktop Connection Broker Node do the following: 1. Install Remote Desktop Services. For more information, refer to "Installing Remote Desktop Services" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN. Note: On the Select Role Services screen, select only Remote Desktop Connection Broker on the Remote Desktop Connection Broker Node. 2. Add a Remote Desktop Session Host Server. For more information, refer to "Adding a Remote Desktop Session Host Server" in the ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN.

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

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

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

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

55 Page 55 of 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 Access Licenses: device-based or user-based, also known as Windows Device CALs or Windows User CALs.

56 Page 56 of 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 Experience screen appears (see page 582 of the Wonderware ArchestrA System Platform in a Virtualized Environment Implementation Guide on WDN).

57 Page 57 of 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 1. Open the Server Manager window. 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.

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

59 Page 59 of 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 1. Open the Server Manager window. 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.

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

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

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

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

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

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

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

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

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

69 Page 69 of 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

70 Page 70 of 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.

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

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

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

74 Page 74 of 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.

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

76 Page 76 of 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.

77 Page 77 of 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

78 Page 78 of 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 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 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.

79 Page 79 of 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 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& IO SERVER INTOUCH RUNTIME 3K TAGS WITHOUT I/O TSE V10.1 INTOUCH RUNTIME 3K TAGS WITHOUT I/O TSE V10.1

80 Page 80 of 1 4 InTouch RT TSE Session 1 3K Tags 3 PLCs No Intouch Session at console InTouch RT TSE Session 1 3K Tags 2 InTouch RT TSE Session 1 3K Tags Windows 2008 R2 Server with Remote Desktop

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

82 Page 82 of REMOTE DESKTOP LICENSING Remote Desktop Licensing (RD Licensing), formally Terminal Services Licensing (TS Licensing) manages the Remote Desktop Services client access licenses (RDS CALs) that are required for each device or user to connect to a terminal server. You use TS Licensing to install, issue, and track the availability of RDS CALs on a Remote Desktop Services license server. When a client either a user or a device connects to a RD Session Host server, the RD Session Host server determines if a RDS CAL is needed. The RD Session Host server then requests a RDS CAL from the Remote Desktop Services license server on behalf of the client attempting to connect to the RD Session Host server. If an appropriate RDS CAL is available from a license server, the RDS CAL is issued to the client, and the client will be able to connect to the RD Session Host server. Note: Remote Desktop Services Licensing is additional to other licenses that might be needed, such as FactorySuite licenses, operating system licenses, and any BackOffice family Access Licenses. If you purchase ThinManager from ACP, it only includes the necessary licenses to run ThinManager. The licenses mentioned above are still required.

83 Page 83 of 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 TseGetId() 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

84 Page 84 of 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 TseGetId() 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, 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

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

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

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

88 Page 88 of 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

89 Page 89 of 1. Click Start on the Windows Taskbar, then Administrative Tools/Computer Management. 2. In the Tree, open Users folder under Local Users and Groups. 3. Double-click a desired user to open the user s Properties dialog box. 4. Click the Member Of tab to activate the Member of property sheet. 5. Remove any default groups and add both the appropriate Wonderware group and the Power Users group.

90 Page 90 of

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

92 Page 92 of 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 Compatible, which chooses the maximum key strength supported by the client computer. The other available options are FIPS Compliant (highest), High, and Low.

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

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

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

96 Page 96 of 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:

97 Page 97 of NEW FEATURES IN USER ACCOUNT CONTROL The UAC functionality is improved so that it: Increases the number of tasks that the standard user can perform, which do not require/prompt for administrator approval. Allows a user with administrator privileges to configure the UAC experience in the Control Panel. Provides additional local security policies that enable a local administrator to change the behavior of the UAC messages for local administrators in Admin Approval Mode. UAC Recommendations You must disable UAC before installing InTouch. You can re-enable UAC after installation for use on a Runtime machine. For InTouch development, UAC must be disabled. For details on disabling UAC in your environment, type UAC into the WDN Search field. NEW FEATURES IN WINDOWS SECURITY AUDITING New Auditing enhancements in Windows Server 2008 R2 increase the level of detail in security auditing logs and simplify the deployment and management of auditing policies. Global Object Access Auditing: Enable the computer s System Access Control List (SACL). Under this the object type can be defined as per file system or registry. Once the list is applied it is applied to every object of type you can configure. It is best recommended to track system files. It is recommended for a wide network. It can track changes done to system files and registry. Reason for access reporting: This list is also called Access Control Entries. The admin can allow privileges to objects. They can allow or deny rights to objects in the environment. Advanced Audit Policy Settings: 53 new settings are available. The new settings allow the admins to target more specific activities.

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

99 Page 99 of 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) 3 rd 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.

100 Page 100 of In their basic role, I/O Servers maintain the list of items that client applications request, then poll or handle data received from field devices, and pass it to subscribed clients. I/O SERVERS IN A TSE ENVIRONMENT Under TSE: The I/O Servers usually run in the console mode under the default system account (unless you specify which user account to run). If the server is running as SuiteLink server, all the client applications should be able to access the I/O server in the "remote" mode (client session). The I/O server will not be able to provide data using the DDE protocol in TSE environment. WHAT HAPPENS WHEN WINDOWVIEWER OPENS When WindowViewer is a client and requires the value of an item, it automatically processes an initiate request to start all I/O conversations and requests the item s value. The server reports the value and updates WindowViewer only if a change occurs. All WindowViewer data requests provide information relating an item to a register, coil number, or I/O data point understood by the server. The server uses the information to automatically handle all messages to and from I/O, hardware devices (PLCs), and/or other data sources. If an I/O Server program does not respond to WindowViewer's initiate request, you can force WindowViewer to try to re-establish the I/O conversation. To start all uninitiated I/O conversations: On the Special menu, click Start Uninitiated Conversations. Note: Executing this command does not affect existing conversations. To restart all I/O conversations: On the Special menu, click Reinitialize I/O. Note: This command closes all existing I/O conversations and restarts the entire process of setting up I/O conversations. All I/O points are affected by this command.

101 Page 101 of 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 object to the OPC Server Node. This implementation provides communications stability. If the OPC Server and the OPC 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).

102 Page 102 of 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.

103 Page 103 of 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.

104 Page 104 of 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.

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

106 Page 106 of 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.

107 Page 107 of 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 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: \intouch!$system 3. Test and verify that the alarms sourced from the alarm provider display correctly in the InTouch AlarmViewer control.

108 Page 108 of APPENDIX 1: RETRIEVING INFORMATION ABOUT THE INTOUCH CLIENT SESSION USING SCRIPTS You can use the following InTouch QuickScript functions for Terminal Services. TseGetId() TseGetNodeName() TseQueryRunningOnConsole() TseQueryRunningOn() TseGetId() 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 TseGetId() function returns an empty string. Syntax MessageResult=TseGetId(); Example The client IP address is saved to the MsgTag tag. MsgTag=TseGetID(); TseGetNodeName() 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 TseGetNodeName() function returns an empty string. Syntax MessageResult=TseGetNodeName(); Example The client node name is returned as the value assigned to the MsgTag tag. MsgTag=TseGetNodeName(); TseQueryRunningOnConsole() Function The TseQueryRunningOnConsole() function can be run from a script to indicate whether the View application is running on a Terminal Services console.

109 Page 109 of 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(); TseQueryRunningOn() 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=TseQueryRunningOn(); 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=TseQueryRunningOn;

110 Page 110 of APPENDIX 2: TECH NOTE 538 INTOUCH TSE VERSION 10.0 APPLICATION CONFIGURATION: MANAGED, PUBLISHED AND STANDALONE METHODS Topic#: 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. 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.

111 Page 111 of CREATING AN INTOUCH FOR TERMINAL SERVICES MANAGED APPLICATION ENVIRONMENT WITH APPLICATION SERVER 3.0 AND INTOUCH 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.

112 Page 112 of 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.

113 Page 113 of 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.

114 Page 114 of 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.

115 Page 115 of 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.

116 Page 116 of 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.

117 Page 117 of 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).

118 Page 118 of MANAGED APPLICATION: FILE LOCATIONS WHEN EXECUTED FROM THE CONSOLE In an operating system such as Windows XP, where the applications are executed from the console, the local working directory is not the one seen in the path of the InTouch Application Manager. Figure 9: Working Directory from XP The source path shown above is the source path for the application. Once WindowViewer is launched the application actually executes from: %ITAPPDATA%\ArchestrA\ManagedApp <which is equal to> C:\Documents and Settings\All Users\Application Data\ArchestrA\ManagedApp

119 Page 119 of 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

120 Page 120 of 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.

121 Page 121 of 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

122 Page 122 of Figure 12: Publish Application Complete 4. Run the application as a Standalone NAD 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.

123 Page 123 of 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 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.

124 Page 124 of 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):

125 Page 125 of 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.

126 Page 126 of Note: The Log pane shows all log messages associated to a specific license. The license details are shown when you select the license file.

127 Page 127 of 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 jan-00 0 ADC6674A13F9D595E121 \ To: VENDOR_STRING=03E HOSTID=ANY\ FEATURE InTouch Wonderware jan-00 uncounted \ VENDOR_STRING=ltags:1000; rrefs:1000; mode:3 HOSTID=ANY\ Parameter Description Possible values ltags: rrefs: mode: Number Of Local Tags excluding the system tags. Number of remote references Former Development/Runtime/ InTouchView application decimal format decimal format 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

128 Page 128 of 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 jan-00 uncounted \ VENDOR_STRING=ltags:61402; rrefs:61402; mode:3 HOSTID=ANY \ FEATURE InTouch_TSE Wonderware 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:

129 Page 129 of 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.

130 RD Session Host 1 InTouch for Terminal Services Deployment Guide Page 130 of 6. On the Confirmation screen, verify that the information matches your expectations and click Install to begin the installation process. ACTIVATE A LICENSE SERVER A license server must be activated in order to certify the server and allow it to issue client licenses. A license server is activated using the licensing wizard, which is located in the Terminal Services Licensing tool. There are four connection methods to activate your license server: Internet, Web, Phone, and Fax. Internet is the quickest and easiest. All four methods access the Microsoft Clearinghouse, which is a facility to activate license servers and to issue client license key packs to the license servers that request them. Windows 2008 R2 Server and Remote Desktop Server Microsoft Certificate Authority and License Clearinghouse TS RD Session Host 2 Microsoft TS Plant

131 Page 131 of 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 (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.

132 Page 132 of 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 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 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

133 Page 133 of 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.

134 Page 134 of 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.

135 Page 135 of 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.

136 Page 136 of 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.