WSP Install Guide

System Platform
Installation Guide
Version 2017 Update 3 SP1

© 2019 AVEVA Group plc and its subsidiaries. All rights reserved.
No part of this documentation shall be reproduced, stored in a ret rieval system, or transmitted by any
means, electronic, mechanical, photocopying, rec ording, or otherwise, without the prior written
permission of AVEVA. No liability is assumed with respect to the use of the information contained herein.
Although precaution has been taken in the preparation of this documentation, AVEVA assumes no
responsibility for errors or omissions. The information in this documentation is subject to change without
notice and does not represent a commitment on the part of AVEVA. The soft ware described in this
documentation is furnished under a license agreement. This soft ware may be used or copied only in
accordance with the terms of such license agreement.
ArchestrA, Aquis, Avantis, Citect, DYNSIM, eDNA, EYESIM, InBatch, InduSoft, InStep, Int elaTrac,
InTouch, OASyS, PIPEPHASE, PRiSM, PRO/II, PROV ISION, ROMeo, SIM4ME, SimCentral, SimSci,
Skelta, SmartGlance, Spiral Software, Termis, WindowMaker, WindowViewer, and Wonderware are
trademarks of AVEVA and/or its subsidiaries. An extensive listing of AVEVA trademarks can be fou nd at:
https://sw.aveva.com/legal. All other brands may be trademarks of their respective owners.
Publication date: Monday, April 22, 2019
Contact Information
AVEVA Group plc
High Cross
Madingley Road
Cambridge
CB3 0HB. UK
https://sw.aveva.com/
For information on how to cont act sales, customer training, and technical support, see
https://sw.aveva.com/contact.
System Platform Installation Guide
Contents
Chapter 1 System Platform Installation .............................................................................. 7
Preparing for System Platform Installation .................................................................................. 7
Important Notice for for Highly Secured Environments (TLS 1.2 Exclusively) ........................... 7
License Installation and Activation ........................................................................................ 8
Sentinel Manager and Agent Installation ............................................................................... 9
Operating System Minimum Requirements ......................................................................... 10
System Sizing Guidelines .................................................................................................. 10
Supported and Recommended Node Hardware Types ........................................................ 11
Required Installation Order of Additional Products ............................................................... 12
Common Components ....................................................................................................... 13
Windows Network Configuration......................................................................................... 13
System Platform Prerequisites ........................................................................................... 14
About SQL Server Requirements.................................................................................. 17
Selecting a Type of Installation........................................................................................... 17
About Product-Based Installation .................................................................................. 18
About Role-B ased Installation ...................................................................................... 20
ArchestrA User Account..................................................................................................... 22
About ArchestrA Us er Account Privileges ...................................................................... 23
Installing System Platform ....................................................................................................... 23
Configuring System Platform Components................................................................................ 32
Configuring the AVEVA Enterprise License Server Location ................................................. 33
Configuring the System Management Server ...................................................................... 34
Import a Certificate ...................................................................................................... 38
User Credentials for Configuring the System Management Server .................................. 38
Configuring the Sentinel System Monitor ............................................................................ 38
Sentinel Manager Configuration ................................................................................... 39
Email Server Configuration........................................................................................... 41
Advanced Sentinel System Configuration ...................................................................... 42
Configuring Databases and Dat a File Locations .................................................................. 43
Configuring the InTouch Web Client ................................................................................... 47
System Restart after Configuration ..................................................................................... 49
Installing InTouc h Access Anywhere ........................................................................................ 49
Install InTouch Access Anywhere S erver ............................................................................ 50
Secure Gateway Installation............................................................................................... 51
Install the Secure Gateway and Aut hentication Server Separately or Together ...................... 52
Install All Components on a Single Server ........................................................................... 54
Modifying an Installation .......................................................................................................... 55
Repairing an Installation .......................................................................................................... 56
Uninstalling System Platform ................................................................................................... 57
Uninstalling System Platform Uninstall a System Platform Component ............................... 57
Uninstall All Components ................................................................................................... 57
Upgrading System Platform ..................................................................................................... 58
Version 2017 Update 3 SP1 3

System Platform Installation Guide Contents
Chapter 2 Security and Permissions ................................................................................ 63

Enhanced Security for Connecting to a Galaxy ......................................................................... 63
Modifying an ArchestrA User Account ...................................................................................... 63
Change the ArchestrA User Account from the CLI ............................................................... 63
SQL Server Rights Requirements ............................................................................................ 64
Setting the SQL Server Security Mode ..................................................................................... 65
Restoring Required SQL Server Accounts ................................................................................ 66
Setting the FIPS Security Policy Option .................................................................................... 67
Chapter 3 Configuring SQL Server ................................................................................... 69

SQL Server Requirements ....................................................................................................... 69
Working with SQL Server Versions........................................................................................... 70
SQL Server not found on node: small configuration ............................................................. 70
SQL Server not found on node: medium and larger configurations ........................................ 71
Compatible version of SQL Server already installed ............................................................ 71
New version of SQL Server already installed....................................................................... 71
Incompatible version of SQL Server already installed .......................................................... 71
Using a Non-Default Port for SQL Server.................................................................................. 71
Setting a Windows Firewall Exception for the SQL Server Port ............................................. 72
Chapter 4 Application Server Upgrade............................................................................. 73

About Upgrading Application Server ......................................................................................... 73
Basic Upgrade S equence ........................................................................................................ 76
Upgrading a Galaxy Repository Node ....................................................................................... 76
Upgrading an IDE-only Node ................................................................................................... 78
Migrating the Galaxy Database ................................................................................................ 78
Upgrading Run-Time Nodes .................................................................................................... 79
Upgrading Redundant Pairs ..................................................................................................... 80
Upgrade Considerations for Multi-Galaxy Communication.......................................................... 84
Issues with Legacy Common Components ............................................................................... 84
Chapter 5 InTouch HMI Requirements and Prerequisites ............................................ 85

Installing OI Gateway and Upgrading from FS Gateway............................................................. 85
Compatibility with Existing FS Gateway Applications ........................................................... 86
FS Gateway Installation Scenarios ..................................................................................... 87
Chapter 6 Historian Server Requirements and Recommendations ............................. 91

Server Requirements .............................................................................................................. 91
High A vailability Support .................................................................................................... 93
Requirements for Historian Management Tools ......................................................................... 93
Remote IDAS Requirements .................................................................................................... 93
Security Considerations for a Remote IDAS ........................................................................ 94
Disk Sizing and Data Storage .................................................................................................. 94
General Hardware Recommendations for Storage ............................................................... 95
4 Version 2017 Update 3 SP1

Contents System Platform Installation Guide
Planning for Disk Space Requirements ............................................................................... 95

Disk Requirements for Database Files ................................................................................ 95
Disk Space Requirements for Historical Data Files .............................................................. 96
Storage and Net work Transmission Sizes for Tags .............................................................. 96
Disk Space Estimation ....................................................................................................... 97
Bandwidth Estimation for Streaming Data ........................................................................... 98
Bandwidth Estimation for Store-and-Forward Data .............................................................. 99
Time Estimation for Store-and-Forward Data..................................................................... 100
About Data Compression and the Buffer Age Limit ............................................................ 100
Performance Considerations .................................................................................................. 100
Server Loading................................................................................................................ 101
IDAS Performance .......................................................................................................... 101
Tiered Historians ............................................................................................................. 102
Storage Subsystem Performance ..................................................................................... 102
Networking Rec ommendations .............................................................................................. 102
Client Access........................................................................................................................ 103
Support for Non-English Operating Systems ........................................................................... 103
Integration with Other Wonderware Products .......................................................................... 104
System Sizing Examples ....................................................................................................... 104
Process Historian Sizing Examples .................................................................................. 104
Server 1 (Non-Tiered): 2.4 GHz Single Processor Quad-Core CPU .............................. 104
Server 2 (Non-Tiered): Four Dual-Core 2.7 GHz CP Us ................................................ 106
Server 3 (Non-Tiered): Four Dual-Core 3.4 GHz CP Us ................................................ 107
Server 4 (Tier-2): Eight Dual-Core 2.67 GHz CPUs (Hyper Threaded) .......................... 109
SCADA (Tiered) Historian Sizing Examples ...................................................................... 110
Topology 1: Centralized Tiered Historian Topology on a Slow/Int ermittent Network ........ 110
Topology 2: Centralized Tiered Historian Topology for a Single Physical Location ......... 112
Topology 3: Simple Tiered Historian Topology for a Modem Configuration .................... 114
Historian Server Installation and Configuration ............................................................... 117

Preparing for the Historian Installation .................................................................................... 117
Microsoft SQL Server Installation ........................................................................................... 117
Historian Installation Features ................................................................................................ 118
About Historian Installation .................................................................................................... 119
Testing the Installation........................................................................................................... 120
Antivirus Software ................................................................................................................. 120
Historian Menu Shortcuts ...................................................................................................... 120
Repairing the Historian .......................................................................................................... 120
Modifying the Historian Installation ......................................................................................... 121
Using HTTPS Instead of HTTP for Historian Client, InSight, and RES T APIs ....................... 121
About TLS Certificates ..................................................................................................... 121
Creating Self-Signed Certificates ...................................................................................... 121
Acquiring a Certificate Thumbprint .................................................................................... 121
Binding Certificates to Secure Socket Layer Ports ............................................................. 122
Updating the Registry for OWINHost to Start in the Secured Mode ..................................... 124
Uninstalling the Historian ....................................................................................................... 124
Upgrading from a Previous Version ........................................................................................ 125

System Platform Installation Guide Contents
About Database Migration................................................................................................ 125

Upgrading the Historian Version ....................................................................................... 125
Migration of History Data Stored in SQL Server ................................................................. 126
Historian Client Requirements ........................................................................................... 127

About the Historian Client ...................................................................................................... 127
Historian Client Components ................................................................................................. 127
Desktop Applications ....................................................................................................... 127
Microsoft Office Add-Ins................................................................................................... 127
ActiveX and .NE T Cont rols .............................................................................................. 128
Requirements and Recommendations .................................................................................... 128
Support for Operating System Language Versions .................................................................. 128
Historian Client Installation and Configuration................................................................. 129

About Historian Client Installation ........................................................................................... 129
Using Historian Client Software with Roaming Profiles............................................................. 129
Repairing the Historian Client Installation ................................................................................ 130
Uninstalling Historian Client ................................................................................................... 130
Upgrading from a Previous Version ........................................................................................ 130
Using Silent Installation ....................................................................................................... 133

Starting Silent Installation ...................................................................................................... 133
User Permissions ............................................................................................................ 134
Configure SQL SysAdmin Permissions ............................................................................. 135
Using Response Files ........................................................................................................... 135
Creating a Response File ...................................................................................................... 136
Response File Samples ......................................................................................................... 137
Role-Based Res ponse Files ............................................................................................. 138
Product-Based Response Files ........................................................................................ 140
Response File Entries to Configure the License Server ........................................................... 141
Response File Entries to Configure the System Management Server ....................................... 142
Single Product Installation .................................................................................................. 143

Guidelines for Creating a Compact Installation Source ............................................................ 143
Upgrading from a Previous Version .................................................................................. 144
Preparation for Installing a Single Product .............................................................................. 144
Optional Folder for Historian ............................................................................................ 146
Creating the Installation Source and Installing the Selected Component ................................... 146
Index ....................................................................................................................................... 149

C HAPTER 1
System Platform Installation
You can use the System Platform installation program to install the entire suite of products or any of the
components.
In This Chapter
Preparing for System Platform Installation ........................................................................................ 7
Installing System Platform ............................................................................................................. 23
Configuring System Platform Components ..................................................................................... 32
Installing InTouc h Access Anywhere .............................................................................................. 49
Modifying an Installation ................................................................................................................ 55
Repairing an Installation ................................................................................................................ 56
Uninstalling System Platform ......................................................................................................... 57
Upgrading System Platform ........................................................................................................... 58
Preparing for System Platform Installation

Before you begin the installation program, you need to prepare your system, and you should plan your
installation according to the two installation types available to you, product -based and role-based. See
Selecting a Type of Installation on page 17 for additional information.
Important Notice for for Highly Secured Environments (TLS 1.2

Exclusively)
Affected Systems
This information is applicable to a small subset of highly secured environments, in which operating
systems and supporting net works have been configured to enable TLS 1.2 and where TLS 1.0 and 1.1
have been purposefully disabled. In these rare instances, s ome additional configuration is required to
ensure that System Platform will work as expected.
System Platform 2017 Update 3 SP1 includes various measures to strengthen security, including the
ability to leverage the latest version of transport layer security (TLS 1.2), provided that TLS 1.2 it has
been enabled and configured in the host operating system.
As of the System Platform 2017 Update 3 SP1 release date, Micros oft Windows Server 2016 does not
support TLS 1.2 by default. You must enable it by applyin g Microsoft updates and several manual edits
to the system registry. The tasks of applying all Microsoft updat es and editing the system registry must
be completed before you install System Platform 2017 Update 3 SP1. These instructions also apply to
any other software products that support TLS 1.2. Follow the instructions listed below.
If you are required to enable TLS 1.2 and disable TLS 1.0 and TLS 1.1:
1. Before installing System Platform 2017 Updat e 3 SP1 on a Windows Server 2016 computer, make
sure that your comput er is up to date by downloading and installing all applic able Microsoft updates.
2. If required by the updat es, restart your computer.

System Platform Installation Guide System Platform Installation
3. Edit the system registry. The .REG file shown below sets registry keys to their safest val ues.
For additional information about these registry changes, see
https://docs.microsoft.com/en-us/dotnet/framework/net work-programming/tls#configuring-sec urity-v
ia-the-windows-registry.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.303
19]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
4. Restart your comput er to ensure that all changes take effect.
5. Install System Platform 2017 Updat e 3 SP1.
License Installation and Activation

A valid product license is required to enable product functionality. The AVEVA Ent erprise License Server
and Enterprise License Manager are automatically selected when you select Application Server or
InTouch, or any role (if you select About Role-B ased Installation on page 20) that includes the
Application Server Galaxy Repository. In some cases, such as when you install a Runtime Client, the
Galaxy Repository is installed "silently" (without any notice it is being installed).
While the Application Server Galaxy Repository is selected for installation, you cannot deselect the
Enterprise License components. The License Server and License Manager are installed on the Galaxy
Repository node by default.
Note: If you are using a workgroup, the License Manager and License Server must be installed on the
same node.
You will need to configure the License Server and activate your product licenses before using the
products you install. For detailed information about product licensing and activation, refer to the AVEVA
Enterprise Electric Licensing Guide (SELicenseManagerGuide.pdf). You can access it after installation
is complete from the AVEVA Enterprise License Manager node, under the AV EV A start directory.
AVEVA Enterprise Licensing
The AVEVA Enterprise License Server ac quires, stores, and serves licenses for all installed AVEVA
software, including all System Platform products. The AVEVA Enterprise License Server and Manager
work together to provide centralized management of all your product licenses.
For products and roles that do not install the License Server on the same node, you will have to provide
the location (node name) of the License Server.
The basic product installation and license activation work flow is:
1. Install System Products, along with the AVEVA Enterprise License S erver and License Manager.
See Installing System Platform on page 23.
2. Configure the AVEVA Enterprise License Server (and Historian, if installed). See Configuring the
AVEVA Enterprise License Server Location on page 33.

System Platform Installation System Platform Installation Guide
3. Start the License Manager. The Licens e Manager is browser -based, and is located in the AVEVA
folder (Start > AVEVA > AVEVA Enterprise License Manager). The License Manager uses the
following URL:
http://localhost/AELicenseManager
Note: If you are running the Licens e Manager from a remote node (not the License Server/Galaxy
Repository node), substitute the node name for localhost.
The License Manager opens in your brows er.

4. If a License Server is displayed, click on it to select it. If no License Servers are dis played, click the
Add Server button, and then enter the computer name of the License Server, or select the computer
name from the drop down.
5. Refer to the AVEVA Enterprise Licensing Help for options and procedures to activat e licenses.
Note: Changes to licensing, such as switching license servers or activating a new license, should not be
done for a product that is already running. Depending on the product, it may take up to 30 minutes to
acquire a new or changed license. To immediately acqui re a license, restart the affected product.
However, product interdependencies may require you to restart the node to force the immediate
acquisition of the license.
Sentinel Manager and Agent Installation

The Sentinel Manager constantly monitors the License Server to ensure that it is accessible. In the event
that the software on a node is unable to acquire a license, the Sentinel Manager sends a warning so you
can quickly fix licensing acquisition issues to ensure that operations are not interrupted.
Sentinel consists of two components:
 Sentinel Agent: The Sentinel Agent is a required component that is installed on all System Platform
nodes. It communicates with the Sentinel Manager to monitor the license ac quisition from the node
to the license server.
 Sentinel Manager: The Sentinel Manager is automatically selected for installation whenever the
Galaxy Repository feature is selected. Not e that you can use the Customize Installation option to
deselect the Sentinel Manager, and then select for installation on a different node. The Sent inel
Manager also has an SMTP server that can send email notifications if a process it is monitoring
requires attention.

Both the Sentinel Manager and Sentinel Agent require configuration after installation. You must
configure the Sentinel Agent on each System Platform node to point to the Sentinel Manager. The
Sentinel Manager also requires configuration of its SMTP server and email addresses for notifications.
See Advanced Sentinel System Configuration on page 42 for additional information.
In addition to the license monitoring functionality that Sentinel provides by default, your System Platform
licenses include the ability to configure Sentinel Manager on a single node to monitor and manage the
performance and availability of the core AVEVA software, the engineered software application(s), and
the relat ed hardware and network infrastructure. To configure this additional functionality, see the
Sentinel User Guide.
Important: If you have a Sentinel license, you can configure the Sentinel Reporting feat ure. This feat ure
is only available for fully-licensed Sentinel System Monitor installations, not basic mode. If your Sentinel
installation will be fully licensed, the SQL Server Reporting Servic es (SSRS ) server shoul d be configured
and the services started before initiating installation of the Sentinel Manager. This will enable
deployment of Sentinel Reports. If SSRS is not configured before installation of the Sentinel Manager,
reports will have to be manually deployed. See the Sentinel User Guide for additional information.
Operating System Minimum Requirements

The following table lists the minimum operating system version for System Platform products. See the
Technology Matrix on the AVEVA Global Customer Support website for the complete list of supported
Windows operating systems.
Minimum Required Operating System Version
Product Client OS (x86 and x64) Server OS (x64 only)
Application Server
InTouch
Windows 8.1 Professional
Windows 10 Version 1607 Windows Server 2012
Historian
AVEVA Enterpris e License Platform
InTouch Access Anywhere Server OS is required
Note: System Platform 2017 Update 3 SP1 is not supported on Windows 10 prior to version 1607
(Anniversary Updat e; OS build 14393).
System Sizing Guidelines

The following table provides guidelines for hardware configurations suitable for System Platform 2017
Update 3 SP 1, based on application size. These guidelines are subject to the limitations of your Windows
operating system, and if applicable, to the SQL Server edition (Express, Standard, or Enterprise). See
the Technology Matrix on the AVEVA Global Customer Support website for supported versions of
Windows operating systems and SQL Server.
 The Intel Itanium 2 proc essor is not supported.
 A minimum display resolution of 1280 x 1024 is recommended for engineering tools such as the
Integrated Development Environment (IDE ).
 A Windows Server operating system is required for large installations with more than 50,000 I/O per
node.
 SQL Server Express is not supported for installations with more than 25,000 I/O per node (small
installations only).

 Pagefile.sys, the Windows paging file (also called the swap file or virtual memory file), must be
enabled. The Windows default setting is enabled.
CPU HD Screen Network

Application Level RAM
Cores Space Resolution Speed
Server Nodes: for Historian Server, GR node, IDE, AppEngine host
Minimum 2 2 GB 100 GB 1024 x 768 100 Mbps

Sm all Application
(1 - 25K I/O per Node)
Recommended 4 4 GB 200 GB 1920 x 1080 1 Gbps
Medium Application Minimum 4 8 GB 200 GB 1024 x 768 1 Gbps

(25k - 50k I/O per
Node) Recommended 8 12 GB 500 GB 1920 x 1080 1 Gbps
Minimum 8 16 GB 500 GB 1024 x 768 1 Gbps

Large Application
(> 50k I/O per Node) Recommended 16 24 GB 1000 GB 1920 x 1080 Dual 1 Gbps
Thin Client Node
RDP clients, ITAA Minimum 1 512 MB N/A 800 x 600 100 Mbps
browsers, mobile
devices Recommended 2 2 GB N/A 1280 x 1024 100 Mbps
Client Node
WindowViewer, Minimum 2 1 GB 100 GB 1024 x 768 100 Mbps

ViewApp, Historian
Client, Remote IDE Recommended 4 4 GB 200 GB 1920 x 1080 1 Gbps
Thin Client-Server Node
Basic RDS - Minimum 4 8 GB 200 GB 1024 x 768 1 Gbps
Basic RDS -
RDS, ITAA Server 8 12 GB 500 GB 1920 x 1080 1 Gbps
Recommended
Supports up to five
remote sessions Large RDS - Minimum 8 16 GB 500 GB 1024 x 768 1 Gbps
Large RDS -
16 24 GB 1000 GB 1920 x 1080 Dual 1 Gbps
Recommended
All-In-One Node
All products on a single Minimum 4 8 GB 200 GB 1280 x 1024 100 Mbps

node
1,000 I/O maximum Recommended 6 12 GB 500 GB 1920 x 1080 1 Gbps
Server node type applies to Historian Server, Galaxy Repository node, and nodes hosting AppEngines.
In redundant environments, increase CPU and RAM to maintain a maximum of 40% typical resource utilization.
Supported and Recommended Node Hardware Types
Product Server Thin Client- Client Node Thin Client All-In-One

Node Server Node
Application Server

Product Server Thin Client- Client Node Thin Client All-In-One

Node Server Node
Galaxy Repository Preferred Supported Supported No Supported
Application Engine Preferred Supported Supported No Supported

IDE Preferred Supported Supported RDP Supported
ViewApp Runtime Supported Supported Preferred ITAA/RDP Supported
InTouch Standalone
Window Maker (No Modern Apps) Supported Supported Preferred RDP Supported
Window Maker (with Modern Apps) Preferred Supported Supported RDP Supported
WindowViewer / InTouch ViewApp (runtime Supported Supported Preferred ITAA/RDP Supported

only)
InTouch for System Platform
Window Maker (with Managed Apps) Preferred Supported Supported RDP Supported
WindowViewer / InTouch ViewApp (runtime Supported Supported Preferred ITAA/RDP Supported

only)
InTouch Access Anywhere
InTouch Access Anywhere Server Supported Preferred No No Supported
InTouch Access Anywhere Client (HTML5 Browser Browser Browser Browser Browser
Browser)
InTouch Access Anywhere Secure Gateway Supported No No No No
Historian
Historian Server Preferred Supported Supported No Supported
Historian InSight Client Browser Browser Browser Browser Browser
Historian Client (Active Factory) Supported Supported Preferred RDP Supported
Support Components
OI Gatew ay Preferred Supported Supported No Supported
AVEVA Enterpris e License Server Preferred Supported Supported No Supported
AVEVA Enterpris e License Manager Preferred Supported Supported No Supported
AVEVA Enterpris e License Manager Client Browser Browser Browser Browser Browser
Required Installation Order of Additional Products

Some Wonderware products releas ed prior to System Platform 2017 Update 3 SP1 must be installed
before you install System Platform. These are:
 Alarm Advi ser 2014 R2 SP1 and prior versions
 Intelligence 2014 R3 and prior versions

 Recipe Manager Plus 2017 Update 1 and prior versions

 Skelta BPM 2017 R2 Updat e 1
If any of the above products will be installed on the same system as System Platform 2017 Updat e 3
SP1:
1. Install the product(Alarm Adviser, Intelligence, etc.) first.
2. Then, install System Platform 2017 Updat e 3 SP1.
InBatch: If you installing InBatch 2017 or a prior version:
1. Install System Platform 2017 Updat e 3 SP1 first.
2. Then, install InBatch.
Common Components
System Platform 2017 Update 3 SP1 includes several shared modules that are needed for the products
to operate. You will see some or all of the following common components listed under Programs and
Features in the Windows Control Panel after installation is complet e, depending on your installation
selections for the node:
Component Version Required/

Optional
AVEVA Platform Common Services 4.3 4.3.18337.2 Required

AVEVA Enterprise License Manager 3.5.10000 Required
AVEVA Enterprise License Server 3.5.10000 Optional (see

note 1)
AVEVA Enterprise Licensing Platform 3.5.10000 Required
Sentinel Agent Install Manager 1.1 SP1 1.1.100 Required
Sentinel Manager 1.1 SP1 1.1.100 Optional
Wonderware Operations Int egration – Core Communications 6.0.0 Required

Driver (G-3.0 Series)
Wonderware Operations Int egration – Supervisory Gateway 6.0.0 Optional (see
Communications Driver (G-3.0 Series) note 2)
Note 1: The License Server is required on nodes with the Galaxy Repository.
Note 2: The Wonderware Operations Integration Supervisory Gateway is present only if InTouch was
installed, or if OI Gateway is selected as part of a custom installation. OI Gateway replaces FS Gateway
that was supplied wit h previous releases. If you are upgrading from a prior version of InTouch, or if FS
Gateway was previously installed as a standalone product, FS Gateway is deleted and replaced by OI
Gateway. See Installing OI Gat eway and Upgrading from FS Gateway on page 85 for additional
information.
Windows Network Configuration

If you are installing System Platform products on more than one node, we recommend that you use
domain based net working. Domain based (client-server) net works provide better user account security
and management than workgroup based (peer to peer) networks.

Note: Do not install the Galaxy Repository on a computer that is used as a domain controller or an Active
Directory server.
Operations that rely on inter-node communications may not function correctly in a workgroup based
Application Server installation. Examples of this type operation include connecting to a remote IDE, or
viewing the status of a remote platform.
If you must use workgroup based networking, you can avoid communications issues by enabling
"everyone permissions" for anonymous users. To enable thes e permissions, go to:
Local Security Policy > Local Policies > Security Options > Network Access: Let
everyone permissions apply to anonymous.
System Platform Prerequisites

Note: If you are using silent (command line) installation, all prerequisites, including the .NET Framework
and SQL Server, must be installed before launching the System Platform setup program. See Using
Silent Installation on page 133 for more information.
System Platform requires two different versions of the Microsoft .NET® Framework (4.7.2 and 3.5
SP1). The two versions run side-by-side.
 Microsoft .NET® Framework 4.7.2: Prior to any other installation task, System Platform checks if
.NET version 4.7.2 is installed. If it is not, you are prompted to allow its installation. A system restart
may be required when .NE T installation is complete. If the System Platform installation program
does not automatically resume after the system restart, you will need to restart it manually.
If an error occurs during setup that stops .NE T Framework 4.7.2 installation, you can try manually
installing from the System Platform installation DV D:
\InstallFiles\Redi st\DOTNET\4.7.2\NDP472-KB4054530-x86-x64-AllOS-ENU.exe
If manual installation does not succeed, the error it is likely due to a missing patch in Microsoft
Windows. For instructions on fixing the issue, refer to the following Microsoft technical not e that
discusses updating Windows 8.1 and Windows Server 2012 R2 in preparation for .NE T Fr amework
4.7.2:
https:// support.microsoft.com/en-us/help/2919355/
 Microsoft .NET® Framework 3.5 SP1: This version of the .NET Framework is a default component
of Windows and is required to enable certain SQL Server functionality, even if you are not instal ling a
product or role that uses SQL S erver directly. If it is not installed, product installation will halt after the
product license agreement screen, and a message is displayed that .NE T 3.5 SP1 must be installed
manually before proceeding.
Since System Platform does not check for .NE T 3.5 SP1 until the installation process has already
begun, you may want to check if it is present prior to starting installation. However, you can activate
or install .NE T 3.5 SP1 without exiting the installation program.
To check installed .NET versions:
1. On the Start menu, choose Run.

2. In the Search box, enter regedit.exe. You must have administrative credentials to run regedit.exe.
3. In the Registry Editor, open the following subkey:
HKEY_LOCAL_MA CHINE\SOFTWARE\Microsoft\NE T Framework Setup\NDP.
4. The installed versions of .NE T are listed.
To activate or install .NET 3.5 SP1:
 In Windows desktop versions, open the Control Panel and go to the Turn Windows features on or
off option.
 In Windows Server versions, open the Server Manager and use the Add Role s and Features
Wizard.
 You can also install .NE T 3.5 SP1 from:
https://www.microsoft.com/en-us/download/details.aspx?id=25150.
Prerequisites Automatically Installed by System Platform
The System Platform installation program analyzes the software installed on your comput er and lists any
software that is required but not currently installed, and any installed soft ware that is incompatible. The
following prerequisites are installed by the System Platform installation program, if not already present
on the system:
 Microsoft .NET® Framework 4.7.2
 Windows Installer 4.5
 SQL Server: SQL Server is required for products or roles that you select for installation that include
GR node or Historian Server. If SQL Server is not present, you are given the option to install SQL
Server 2014 SP2 Express with Tools as part of System Plat form installation. However, SQL Server
Express supports only small installations with less than 25,000 I/O per node.
If you have a medium or large installation, a copy of SQL Server 2016 SP1 Standard Edition is
supplied with System Platform. You must install it or another supported version of SQL Server
separately, before you install System Platform. See the Technology Matrix on the AVEVA Global
Customer Support website for the current list of supported SQL Server versions.

If you do not want to install SQL Server, and you have product or role selections that include the GR
node by default, you can select the Customize Installation checkbox and deselect the
Galaxy_Repository. However, this will limit any database-relat ed product functionality, such as the
Application Server IDE, that uses the Galaxy Repository.
See SQL Server Requirements on page 69 for more information about the limitations of using SQL
Server Express instead of a standard or enterprise edition.
The following tables summarize which System Platform products and roles require SQL Server.
SQL
System Platform Product Selections Required
Application Server Yes
Application Server and InTouch OMI Runtime No
Application Server Development No
Application Server Galaxy Repository Yes
InTouch HMI Yes
InTouch Development and Runtime Yes
InTouch Runtime Only No

InTouch Access Anywhere Server No
InTouch Access Anywhere Secure Gat eway No
InTouch Access Anywhere Authentication Server No
Historian Yes
Historian Client No
Licensing No
SQL
System Platform Role Selections Required
Runtime Client No
Remote System Platform Development Client No
System Platform Development Server Yes

 Without Galaxy Repository (custom installation) No
Historian Server Node Yes
Historian Client Node No
InTouch Access Anywhere Secure Gat eway Node No

SQL
System Platform Role Selections Required
All-In-One-Node Yes
 Without Galaxy Repository and Historian Server (custom No
installation)
Note: System Platform will allow you to install an InTouch development system without a Galaxy
Repository. However, InTouch Modern Applications will not work without the Galaxy Repository.
While installing System Platform, if the logged-on user (the installer) is not a SQL S erver administrator,
the SQL Acce ss Configurator opens (the dialog box is labeled "aaConfig SQL") and requests SQL
Server administrator credentials. Enter valid SQL Server administrat or credentials when requested. For
more information about setting user privileges with the SQL Acce ss Configurator, see Setting the SQL
Server Security Mode on page 65. For more information about SQL Server installation, see About SQL
Server Requirements on page 17.
The System Platform installation program installs both system-specific and product-specific
prerequisites. It also checks for incompatible software that will prevent installation from proceeding, (for
example, if InTouch Access Anywhere was previously installed). You do not have to exit from the System
Platform installation program to install the prerequisite software, with the exception of standard or
enterprise versions of SQL Server. You will need to exit and perform any uninstall operations that are
indicated before continuing with installation.
For information on prerequisites and software requirements for the specific products, see the System
Platform Readme, the Readme files of the specific products located in your doc ument ation directory, or
the specific product information chapter in this installation guide.
About SQL Server Requirements

The exception to the prerequisites installation workflow is the SQL Server requirement for System
Platform products. In most cases, SQL Server is required when you install:
 Application Server
 Historian
 InTouch HMI (when used with modern applications)
If a supported version of SQL Server is not already installed, you must exit the installation program,
install the supported SQL Server version, then res ume the installation. We recommend that you install
and configure the supported SQL Server version before you begin the System Platform installation
program.
Note: If you are installing a small system (less than 25000 I/O), you can use SQL Server Express instead
of a standard version of SQL Server. You can elect to install SQL Server Express as part of the System
Platform installation process; you do not have to install it separately.
For more information about SQL Server prerequisites, see SQL Server Requirements on page 69.
Selecting a Type of Installation

The System Platform installation program offers you a choice of two types of installation—
product-based or role-based.

About Product-Based Installation

Product-based installation provides a combination of features not specific to a node. This is the preferred
installation type for a stand-alone product installation.
If you are familiar with System Platform products and their associated components, you can opt for a
product-based installation, and then choose the components that you need. For example if you need to
®
install InTouch with the default options, then select a product-based installation.
Important: Product-bas ed installation includes an option to install the InTouch Access Anywhere Sec ure
Gateway. This option can only be installed on a computer running a supported version of the Windows
Server operating system (minimum: Windows Server 2012). No other System Platform components can
be installed with it.
In the table below, components that are selected by default when you select the corresponding product
are indicated by the letters R (for required), and O (for optional). Required means that the component
must remain selected to install the product. Optional means that you can deselect the component and
retain the remaining product functionality. Products definitions (columns 2 through 8) are as follows:
 AS + GR: Application Server (with Galaxy Repository)
 AS no GR: Application Server (wit hout Galaxy Repository)
 IT: InTouch (HMI)
 ITAA: InTouch Access Anywhere
 ITAA SG: InTouch Access Anywhere Secure Gateway
 ITAA AS : InTouch Access Anywhere Aut hentication Ser ver
 HS: Historian Server
 HC: Historian Client
Product / Component AS + AS no IT ITAA ITAA ITAA HS HC

GR GR SG AS
System Platform
 ASB Runtime R R R R R
 ASB Service Repository R O R
 ASB Management Server O O O O
Application Server
 Bootstrap R R R R
 IDE O O R
 Galaxy Repository O O O
InSight Publisher R R

Product / Component AS + AS no IT ITAA ITAA ITAA HS HC

GR GR SG AS
InTouch HMI
 Runtime R R
 Development O
 Alarm DB Logger R R
 Demo Apps O
 Recipe Manager O R
 SQL Access O R
 16 PenTrend
O R
 Symbol Factory
R R
 InTouch Web Client
R R
 OI Gateway
InTouch Acce ss Anywhere
 ITAA Server R
 ITAA Secure Gateway R
 ITAA Authentication R
Hi storian
 Historian Server R
 IDAS R
 Active E vent R
 Configuration Tools R
 Historian Extensions R
Hi storian Client
 Trend/Query Clients R R R R R
 Microsoft Add-Ins
Licensing
 License Manager R O R O
 License Server R O R O
Client Components R R R R
Server Components R R R R
OI Server Simulator R R R R
Sentinel
 Sentinel Manager R
 Sentinel Agent R R R R O O R R
R = Required

O = Optional
About Role-Based Installation

Role-based installation provides a combination of features specific to a node. If you are uncertain about
the specific products or components you need, but you know what role your computer will play, you can
opt for a role-based installation. For example, if your computer is a run-time node or a development node,
you can select those roles in the role-based installation program. The System Platform installation
program will install all components required for the roles that you have selected. It is recommen ded that
you define the node you are installing and select the appropriate role before starting the installation
program. During the installation, you can click a role to see its description, as described in Installing
System Platform on page 23.
Important: Role-based installation includes an option to install an InTouch Access Anywhere Secure
Gateway node. This option can only be installed on a computer running a supported version of the
Windows Server operating system (minimum: Windows Server 2012). No other System Platform
components can be installed wit h it.
In the table below, components that are selected by default when you select the corresponding product
are indicated by the letters R (for required), and O (for optional). Required means that the component
must remain selected to install the product. Optional means that you can deselect the component and
retain the remaining product functionality.
Note: In some cases, you can still deselect a product category to remove all components under it, even
if components are marked as required. For example, if you are installing a System Platform Development
Server, and will be using the InTouch OMI run time only, you can deselect the InTouch HMI category to
remove all the components listed under it, including components that are marked as required. As anot her
example, if you are installing Security Server, it is possible to deselect the ASB Management Server, but
the resulting installed product will not result in a Security Server.
Products definitions (columns 2 through 8) are as follows:

 RT Client: Runtime Client. Install only the necessary components required to run a visualization
client, Historian client, and ArchestrA object server run-time components.
 Dev Client: Remote System Development Workstation. Install the components required for a
remot e engineering development workstation with only the required c omponents to allow the node to
connect to an existing development server; GR is not installed by default. It allows development and
testing of InTouch and System Platform applications.
 Dev Servr: System Platform Development Server. Install the components required to host the
development server, and develop and test InTouch and System Platform applications.
 HS Node: Historian Server Node. Install the necessary components to store historical dat a in an
ArchestrA environment.
 HC Node: Historian Client Node. Install the components required to connect to an existing Historian
Server and analyze the data.
 ITAA SG: InTouch Access Anywhere Secure Gateway Node. Install the components to access
InTouch applications hosted on Terminal Servers by using HTML5 compatible web browsers. This
component cannot be installed on a computer that has other System Platform components installed.
 Lic Srvr: License Server. Installs the components required to creat e a stand -alone license server
that installed products on other nodes can access for their licenses.
 Sec Srvr: ASB Security Management Server. Installs the components required to create an ASB
Management Server to provide encryption via the TLS protocol, single sign -on, and certificate
management across a galaxy. See Configuring the System Management Server on page 34 for
additional information.

 Snt Mgr: Sentinel Manager. Installs the Sentinel Manager and Agent components. The Sentinel
Manager monitors the License Server. It also includes a single node license to monitor the health o f
the computer on which it is installed.
Note: The Sentinel Manager is automatically selected for installation whenever the Galaxy
Repository component is selected. You use the "Customize Installation" dialog to deselect it.
Not Listed: The following roles are not defined in the table below:
 All-in-One Node: All products, except InTouch Any where, are installed on a single node.
 Custom: Allows you to customize the components that are installed. No components are selected
by default; you must select any component that you want to install.
Role RT Dev Dev HS HC ITA Lic Sec Snt

Client Client Servr Node Node A Srvr Srvr Mgr
SG
System Platform
 ASB Runtime R R R R R R
 ASB Service Repository R
 ASB Management Server R R
Application Server
 Bootstrap R R R O O
 IDE R R
 Galaxy Repository O
InSight Publisher R R R
InTouch HMI
 Runtime R R R R
 Development O O
 Alarm DB Logger R R R R
 Demo Apps O O
 Recipe Manager O O O R
 SQL Access O O O R
 16 PenTrend
O O O R
 Symbol Factory
R R R R
InTouch Acce ss Anywhere
 ITAA Server
 ITAA Secure Gateway R
 ITAA Authentication

Role RT Dev Dev HS HC ITA Lic Sec Snt

Client Client Servr Node Node A Srvr Srvr Mgr
SG
Hi storian
 Historian Server R
 IDAS R
 Active E vent R
 Configuration Tools R
 Historian Extensions R
Hi storian Client
 Trend/Query Clients R R R R R R
 Microsoft Add-Ins
Licensing
 License Manager O O R O
 License Server O O R R
Operation Integration
 Client Components R R R R R
 Server Components R R R R R
 OI Server Simulator R R R R R
 OI Gateway R R R R
Sentinel
 Sentinel Manager R R
 Sentinel Agent R R R R R R R R R
R = Required
O = Optional
ArchestrA User Account

The ArchestrA User Account is a user name and password combination that enables inter-node
communication bet ween all computers in an Arches trA environment. You must specify the same user
account on every node when you install the System Platform components for the first time on computers
that communicate with each ot her.
Wherever an Arc hestrA User Account is required, the System Platform Inst allation dialog box appears
and you will need to provide a valid user name and password.
WARNI NG! The Arche strA User Account i s a Windows operating system account located on the
local computer or on a domain. Do not delete this account with operating system account
management tools. If you do, ArchestrA-enabled software may stop functioning properly.
 If no other ArchestrA-enabled software is installed on the computer, you are prompted to create a
new A rchestrA User Account or specify an existing user account during the System Platform
installation.

 If y ou use an existing user account, it must have a permanent password that does not expire, and the
password cannot be changed. By default, the local machine name is displayed. To use a domain
user account, enter the short domain name. Do not use the fully qualified domain name (FQDN). For
example, use "DomainName" and not "DomainName.com" or " DomainName.local."
Important: To enhance security, the ArchestrA User Account is blocked from logging on to the Galaxy
locally or through Remote Desktop Services by default. This is configured in the operating system user
rights management.
About ArchestrA User Account Privileges

When you install System Platform, you can choose to have the system automatically create the
ArchestrA User as a local account. The ArchestrA User account cannot be used to interactively log on to
the computer.
If you specify a pre-existing user account as the ArchestrA User, it is added to the group
aaAdministrators. Any SQL Server privileges that Application Server requires are also added. See SQL
Server Rights Requirements on page 64 for more information.
If the existing account is a system administrator, it is removed from the system Administrators group to
enhance security.
Note: Members of the aaAdministrators group do not have system admin privileges.
See Modif ying an ArchestrA User Account on page 63 if you need to change or recreate the ArchestrA
User Account.
Installing System Platform

IMPORTANT! We strongly rec ommend that you log into Windows as a user with administrative
privileges when launching setup.exe. Once all selected System Platform products are installed and
configured, you can use a lower-privileged account to operate the system.
If you use a standard user account with temporary administrator credentials instead of an administrator
account to run setup.exe, a registry flag associated with the temporary administrator account may
remain after the system prompts for a mid-installation restart. This flag is used to notify the operating
system that setup should resume the next time that particular us er logs into the system. Since product
installation may have already completed the next time the user logs in, the "modify" setup screen
appears instead. If this occurs, simply cancel the modify setup screen. This scenario, if it occurs, will only
happen once, since the registry flag will be cleared. This will not affect the products or their installation.
You can select a product-based or a role-based installation for your comput er.
Note: Prerequisites are installed as part of product installation and not in a separat e workflow.
To install System Platform

1. Insert the DVD into your DVD-ROM drive. Depending on your c omputer's security settings, Windows
User Access Control may ask for permission to run the installation program. Allow it to run, and the
startup screen appears. If your net work or company security policy does not permit autorun, browse
the root directory of the DVD and run setup.ex e.
 If the operating system is not supported, you blocked from continuing. See Operating System
Minimum Requirements on page 10 for additional information.
 If the operating system is supported, basic installation requirements are checked. .NET 4. 7.2 is
installed if it or a lat er version is not already present.

Note: Y ou are prompt ed to restart your c omput er after the .NE T framework is installed. Y ou may
need to manually restart the setup program. If the .NE T Framework does not install successfully,
see System Platform Prerequisites on page 14 for additional information.
2. After some automatic configuration occurs, the select installation mode dialog box appears.
3. Select whether you want a product-based or a computer role-based installation, and then click Next.
The select options dialog box appears. Its appearance will vary, depending on whether you chose
product-based or role-based installation.
 For information about product-based installation, see About Product-Based Installation on page
18.
 For information about role-based installation, see About Role-B ased Installation on page 20.
 If you are installing any of t he InTouch Access Anywhere options available under P roduct-Based
Installation, see Installing InTouch Access Anywhere on page 49.

If you select the Product Ba sed Selection option, the product based installation dialog box
appears.
If you select the System Platform Computer Roles option, the role based installation dialog box
appears.
You can select multiple products or roles. All the selected components will be i nstalled together. If
you are installing InTouch Access Anywhere Secure Gateway, it must be installed by itself, without
any other System Platform components.
When you select the Galaxy Repository for installation, the following components are automaticall y
selected for installation and cannot be deselected:

o ASB Service Repository. The ASB Service Repository includes a System Management
Server, used for establishing a trust relationship bet ween machines. See Configuring the
System Management Server on page 34for additional information.
o AVEV A Enterpri se License Server and Manager. Every node should be configured to point to
a single License Server. See Configuring the AVEVA Enterprise License Server Location on
page 33 for additional information.
o Sentinel Manager. Every node should be configured to point to a single Sentinel Manager. See
Configuring the Sentinel S ystem Monitor on page 38 for additional information.
Note: If you have multiple Galaxy Repository nodes, the Configurator lets you select which node(s)
to use for the above components at the end of installation. See Configuring System Platform
Components on page 32 for more information.
4. Select the check boxes to indicate whic h products or roles you want to install, and then click Next.
The verify selection dialog box appears.
5. To proceed with your selections without making any changes, click Next. To change your
configuration, select the Customize Installation check box before clicking Next. Use the Customize
Installation to make modifications to add or remove optional components for the products you have
selected for installation. For example use Customize Installation to:
 Remove components from a node in multi-node Application Server configurations, such as the
IDE or Galaxy Repository.
 Add components, such as the InTouch 16 -Pen Trend Wizard supplementary component.
Note: The ASB Service Repository is automatically selected when you select the Application Service
Galaxy Repository. It cannot be deselected, unless you first deselect the Galaxy Repository
component. However, you can choose not to use it when you configure security. See Configuring the
System Management Server on page 34 for details.
6. Optional: Complete the following installation steps to install InTouch HMI supplementary
components and make other changes:
a. Select Customize Installation.

b. Click Next. The customize installation dialog box appears.
c. Scroll through the list of System Platform products to be installed to the InTouch
Supplementary Components section.
d. Select InTouch 16 PenTrend from the list.
– You can make ot her product and component selections.
– You can click Browse on the customize installation dialog box to change the program
installation destination folder.
e. Click Next to continue the remainder of the installation procedure.

7. If you have selected an InTouch HMI features, the language selection dialog box appears. Select
the language for your InTouch HMI installation. The InTouch language versions are supported only
for the matching operating system language. For example, the German version of the InTouch HMI
is only supported on the German operating system.
8. Click Next. The End User License Agreement dialog box appears.
9. Review the license(s). Click I have read and accept the terms of the license agreement(s), and
then click Agree.
10. If the products or roles you selected require it, the Arche strA User Account dialog box appears.

Note: If an Archestra Us er Account is NOT required (for example, if you are only installing Historian
Client ), you will be prompted to click Install. If this is the case, skip to step 12.
11. Specify an ArchestrA User Account. You can specify an existing user account, or creat e a new
ArchestrA User Account if no ot her Arc hestrA-enabled software is installed on the computer. The
ArchestrA User Account is used for encrypted communication between different ArchestrA nodes
and software components.
 To select an existing user account:
a. Clear the Create Local Account check box. When you clear the check box, the Domain/Local
Machine text box displays the default domain name. Specify a different domain/local machine
name if necessary.
b. Type the user name and password for t he existing account. The account must meet the following
requirements:
– The account must have a permanent password that does not expire.
– The account must have a password that cannot be changed.
c. Click Next to complete the User Account setup.
 To create a new account:

d. Click the Create Local Account check box if not already selected. By default, the
Domain/Local Machine box displays your computer name.
e. Type your us er name and password.

12. If the products or roles you selected require Microsoft SQL Server, and a supported version of SQL
Server is not already installed, you will be prompted to select either automatic installation of SQL
Server Express, or to exit and manually install a full version of SQL Server.
Caution: If you s elect SQL Server Express, System Platform will automatically grant you (the logged
in user) SQL sysadmin privileges. This level of access is required to proceed with SQL Server
Express installation. Y ou will retain sysadmin privileges even after installation. If you need to remove
sysadmin privileges from the logged in account, be sure to create a sysadmin account first.
 Click Yes to use SQL Server Express. SQL Server Express is adequate for systems with less
than 25000 IO. It will be installed automatically along with the other prerequisites and the
selected System Platform components.
 Click No to skip SQL Server Express installation. Then, click Exit and manually install SQL
Server. System Platform for medium and large installations includes a separate DV D with a full
version of SQL Server 2016 SP1 Standard. However, you can install any supported version of
SQL Server. See the A veva Global Customer Support (GCS ) Technology Matrix for a list of
supported SQL Server versions.
When you have finis hed SQL Server installation, restart the System Platform installation
program.

13. A list of missing prerequisite components (if any) and the System Platform products to be installed
are displayed.
Note: Any prerequisites required for the products selected for installation will be listed above the list
of products and components. The prerequisites will be installed first, and the product and
components will be installed immediately after installation of the prerequisites has finished. If you
elected to install SQL Server Express, it will be installed along with any other prerequisites.
14. Click Install to proceed. The progress bar appears.

15. After the installation is over, the installation completed dialog box appears.
 Select View Readme for important information, including hardware and software requirements,
new features, and known and resolved issues.
 Select Configure to continue. See Configuring System Platform Components on page 32 for the
final steps to complete installation .
Configuring System Platform Components

The AVEVA Enterprise License Server, security (System Management Server), and the Historian Server
require post-installation configuration for initial setup. You need to configure your products using the
Configurator dialog box after you have installed them. The Configurator dialog box lists all product
components that require post-installation configuration. You can configure the locations for the product
database and the data files.
You must have administrator rights to use the Configurator.

To start the Configurator

 Click Configure on the final installation dialog box. The Configurator dialog box appears. The
product feat ure tree expands by default. Most features will show as Not Configured the first time you
open the Configurat or.
The status of each item in the Configurator is displayed when the Configuration opens and as items are
configured. The status indicators are:
o Error - Indicates that an error occurred during configuration.
o Not Configured - Indicates that the feat ure is installed, but not configured.
o Warning - Indicates that configuration is complete, but with warnings.

o Configured - Indicates that configuration completed successfully.
o Not Installed - Indicates that the feature is not installed.
Configuring the AVEVA Enterprise License Server Location

Detailed information about configuring the AVEVA Enterprise Licens e Server is contained in the AVEVA
Enterprise License Platform Guide. This guide can be accessed from the AVEVA Enterprise License
Manager (see License Installation and Activation for additional information). The basic steps to configure
the location of the AVEVA Enterprise License Server are:
1. In the left pane, select AV EVA Enterpri se License Server. Then, in the right pane enter:
 Primary Server Name: if the License Server is not installed on the local node, enter the License
Server name, or select a server name from the drop down list of previously -configured License
Servers (if any).
 Server Port: default is 55555

Note: To see if the license server can be found after entering the Server Name and Port, you can
press Test Connection.
 Backup: If you have configured a backup server (sec ondary server), select the checkbox to
enable backup. Then, enter the secondary server name.
2. Press the Configure button.

3. Select the next item in the left pane that requires configuration. When all required items have been
configured, press the Close button to complete installation. See System Restart after Configuration
on page 49.
Configuring the System Management Server

Security measures for System Platform 2017 Update 3 SP1 include support for the TLS 1. 2 protocol for
secure encrypted communications between nodes, single sign on (SSO), and certificate management.
These features, available since the release of System Platform 2017 Update 3, are enabled through a
component of the ASB Runtime called the System Management Server. To enable security, every
System Platform node must communicate with the System Management Server, and there should only
be a single System Management Server in your System Platform topology. The System Management
Server stores shared security certificates and establishes a trust relationship between mac hines.
If some nodes have not been upgraded to System Platform 2017 Update 3 or lat er, communication with
those older nodes will continue to utilize unsecured communication. Howeve r, communication bet ween
nodes running System Platform 2017 Update 3 or Update 3 SP1 will be encrypted, as long as the nodes
are configured to communication with the System Management Server.
To configure the System Management Server
1. In the Configurat or, select System Management Server under Common Platform in the left pane.

Note: If you are prompted for user credentials for the System Management Server, use the following
format to enter the user name: DomainName\UserName. The prompt for user credentials may be
displayed if you have domain admin privileges but are not an admin on the local machine. You must
be a member of the Admini strators or aaAdministrators OS group to configure the System
Management Server. For more information, see User Credentials for Configuring the System
Management Server on page 38.
Note: The Configurator is automatically invok ed when installation completes. You can also start the
Configurator at any time after from the Windows Start menu on any System Platform node.
2. You are presented with three choices:

 Connect to an existing System Management Server: This is the default option. The System
Platform discovery service looks for any existing System Management Servers on its network. If
any are found, they will be displayed in a drop down list. Select the server you want to use, or
enter the machine name of the server. All computers in your System Platform topology should
connect to the same server.
 This machine is the System Management Server: Select this option if this computer will be
the System Management Server. All other comput ers in your System Platform topology should
the be configured to connect to this server by using the Connect to an existing System
Management Server option.
 No System Management Server configured. (NOT RECOMMENDED): Select this option to
set up your computer without encryption and secure communications. You can still configure
other computers in the topology to use a System Management Server.

3. Advanced settings: This opens the Advanced Configuration dialog window.
 Certificate Source: Select either Automatically Generated (default), or Provided by IT. If

your IT department is providing the certificate, press the Import button and navigate to the
certificate file. For more information, see Import a Certificate on page 38.
Certificate: The certificate name is displayed. If you imported a certificate, you view it by
pressing the Details button. The certific ate is periodically renewed through an automatic update
process, both on the server node and on rem ote nodes.
 System Management Server: If you are connecting to an existing System Management Server,
the name and port number of the server you selected is shown.
 Common Platform Ports: The ports for t he common platform are used for communications with
certain AVEVA software, such as the Sentinel System Monitor. Generally, you can use the
default settings. Remote nodes must be configured with the same port numbers as configured
here. Click the Advanced button, then edit the port numbers as needed.
Default HTTP port: 80
Default HTTPS port: 443

4. Press the Configure button. A Security Warning window is displayed:
By establishing trust between machines, communications can pass freely. This will be a security
concern if you are not sure of the identity of the remote computer. If you have any doubt about the
computer you are connecting to, verify the security code and certificate details by selecting the
Details... button in the Advanced Configuration dialog to open the certific ate.
on page 49.

Import a Certificate
To import a signed CA certificat e, select the Provided by IT option from the Certificate Source drop
down menu. The Import Certific ate dialog wi ndow opens.
1. Navigate to the Certificate file by pressing the browser button. Select the Certificate file and
press Open. The Certificate file must have a .PFX extension.
2. Select the Certificate Store in which to save the Certificate, as directed by your IT department.
3. Enter the Certificate password.
User Credentials for Configuring the System Management Server

In some circumstances, when configuring the System Management Server, you may be prompted to
enter your user credentials. This may happen if the logged in user does not belong to the
aaAdministrators or Admini strators OS group. If you are a member of either of thes e groups, enter
your user name as DomainName\UserName.
If you are not a member of aaAdmini strators or Admini strators on the local machine, you can obtain
configuration privileges by editing the file appsettings.j son, and adding the name of the OS group to the
file. The full path for this file is:
C:\Program Files (x86)\AVEVA\Platform Common Services\Management Server\appsettings.json.
To add configuration privileges for the System Management Server to an OS group, add the name of the
OS group to the json file, after "aaAdministrators."
"AppSettings": {
"AllowGroups:: [
"aaAdministrators",
"insert new group name here"
]
Configuring the Sentinel System Monitor

The Sentinel System Monitor cont ains two configuration items:
 Sentinel Manager (Sentinel Agent Install Manager): The Sentinel Agent Install Manager (SAIM)
specifies the name or IP address of the Sentinel Manager. By default, the Sentinel Manager is
selected for installation on the Galaxy Repository node, but you have to configure the location of the
Sentinel Manager on each node in the System Platform topology. This allows the Sentinel Agent to
communicate with the Sentinel Manager.
 Alert Email Server: The name of the email server and accounts that will be us ed to send and
receive alerts from the Sentinel Manager. This is configured on the Sentinel Manager node only. You
must have SQL Server administrator rights to configure the email server.
There should only be one Sentinel Manager in a System Platform topology, but each node contains a
Sentinel Agent. See Sentinel Manager and Agent Installation on page 9 for more information.

The email server sends email alerts generated by the Sentinel Monitor to notify personnel that an issue
has been det ected and may require attention.
Sentinel Manager Configuration

By default, the Sentinel Manager is installed on the Galaxy Repository node. There should only be one
Sentinel Manager per System Platform topology, and eac h node should be configured to point to it.
1. In the Configurator, select Sentinel Manager, under Sentinel System Monitor.
 If the System Platform node does not include Historian or MES, the initial Sentinel Manager
Configuration window contains a single field for the Sentinel Manager name.

 If the System Platform node includes Historian or MES, the initial Sentinel Manager
Configuration window contains additional fields to define credentials for MES and/or the
Historian.
2. In the Sentinel Manager Name field, enter either the computer name (preferred) or IP address of
the node that will act as the Sentinel Manager. If you are configuring the current node as the
Sentinel Manager, enter its name or IP address. If you have configured secure communications for
the Common Platform, the machine name must be used (IP address is not supported for secure
communications). See the Sentinel Us er Guide for additional information.
Note: TCP/IP is used for communications bet ween Sentinel Agents and the Sentinel Manager. Use
the Advanced settings configuration dialog to configure the TCP/ IP port numbers. See Advanc ed
Sentinel System Configuration on page 42 for additional information.
3. If either Historian or MES is installed on the node, the Configurator detects the installation. It allows
you to specify credentials for these programs to use to increase security. If MES or Historian is not
installed, credential fields are not displayed a nd you can skip this step.
 If MES i s installed on the node: To enable secure communication between MES and Sentinel
Manager, select the checkbox next to "Enter the MES credentials." If you do not select the
checkbox, communication between MES and Sentinel Manager is unsec ured.
If you selected the checkbox, enter the user name and password of a configured MES user. The
Sentinel Manager uses the configured user to communicate with MES.

 If the Historian is installed on the node: To enable secure communication between the
Historian and Sentinel Manager, select the checkbox next to "Enter the Historian credentials." If
you do not select the checkbox, communication between the Historian and Sentinel Manager is
unsecured.
If you selected the checkbox, enter the user name and password that was configured for the
Arche strA User. The Sentinel Manager uses the ArchestrA User Account to communicate with
the Historian. See ArchestrA User Account on page 22 for more information.
4. You can use the Te st Connection button to check that the node you are configuring can reach the
Sentinel Manager node.
on page 49.
Email Server Configuration

Configuring a Sentinel Alert Email Server is optio nal. This procedure establishes an existing email server
that the Sentinel Manager can use to send alerts. This is configured on the Sentinel Manager node only.
Note: You must have SQL Server sysadmin rights to configure the email server. No warning will be
displayed, but without the proper user rights, configuration changes you make to the Alert Email Server
in the Configurator will not be accepted.
1. In the Configurator, select Alert Email Server, under Sentinel System Monitor.
2. Select one of the email alert details options.

 To skip email server configuration, choose the option to enter email server details later.
 To configure the email server, choose the option to "Enter Email server details now."
3. In the SMTP Server Name or IP field, enter either the computer name or IP address of the email
server to be used for Sentinel alerts.
4. In the SMTP Server Port field, enter the port number of the email server (default: 25).
 Use port number 25 for an unsecured SMTP server.
 Use port number 465 for a secured SMTP server.
See the Sentinel User Guide for additional configuration information.
5. In the SMTP Server Secured field, enter ye s if the server is secured, or no if it is not.
6. If you are using a secured email server, enter the user name and password to access the server.
The user name and password field are only applicable to a secured email server.
7. In the From Email ID field, enter the email address that will be used to send system alerts from the
Sentinel System Monitor.
8. In the Default Recipient Email ID field, enter the email address(es) that will receive system alerts
from the Sentinel System Monitor.
on page 49.
Advanced Sentinel System Configuration

An instance of the Sentinel Agent is installed on every node. Each agent communicates with the S entinel
Manager through TCP/IP and uses the Common Plat form settings. Each Sentinel Agent must use the
same port number that was configured for the System Management Ser ver. See Configuring the System
Management Server on page 34 for additional information.
If you have changed the default port settings for the System Management Server, use the Advanced
Configuration settings to configure the TCP/ IP port numbers for Sentinel.
To configure the Sentinel Manager TCP/IP Port Numbers
Note: Configure the System Management Server before you configure the Sentinel Manager ports.
1. In the Configurator, select the Sentinel Manager entry, under Sentinel System Monitor.

2. Click the Advanced button. The Advanced Configuration dialog window opens.
3. Set the port number. Unless you changed default port numbers, no changes should be needed.
 If System Platform is configured to use a secure mode of operations, that is, if the System
Management Server option is configured, set the SSL port to the same number that was
configured for Common Plat form communications. The default SSL port is 443.
 If security is not configured for System Platform, that is, if no System Management Server option
is configured, set the HTTP port to the same number that was configured for Common Platform
communications. The default HTTP port is 80.
4. Press OK, and then Close to exit Advanced Configuration.
5. Select the next item in the left pane that requires configuration. W hen all required items have been
on page 49.
Configuring Databases and Data File Locations

You can use the Configurator to configure Historian settings.
Note: Before running the Configurator, be sure SQL Server is installed and running. Also, be sure you
have SQL Server administrator rights.
You can start the Configurat or at any time from the Windows Start menu on the Historian computer.
 To configure ArchestrA Service Bus settings, see Configuring the System Management Server on
page 34.
 To configure licensing, see Configuring the AVEVA Enterprise License Server Location on page 33.
To configure the databases and data file folders
1. Start Configurator from the Start menu.

2. In the left pane, click Server. Then configure the databases as follows.
a. Under Database Information, specify the SQL Instances and database path.
– SQL Instance
Name the SQL Instance associated with this historian.
– Database Path
Unless you have specific requirements, keep the default SQL Server database path. This is
the path where the configuration database is deployed. Click the ellipsis button to specify a
different directory in which to install the historian databas e files.
b. Under Existing Databa se Conflict, read any notices.
If the database is created for t he first time, then this option is not available. When reconfiguration
is done, then the Drop and Create New Database option is available. If you select this check
box, then the existing database is dropped and a new dat abas e is created. If this check box is
cleared, then the database is not dropped, but configured for changes, if any.
c. Under Alarms & Events Storage, configure how you want to store alarm and events.
Important: If you want to change this setting later aft er the Historian is running, you must first
shut down and disable the historian using the Management Console. Then, after making the
change, you can restart and enable the historian.
– High-speed (default/recommended)
The high speed setting for storing alarms and events in history blocks provides several
advantages. You can manage the data using simple operations such as moving, copying, or
deleting folders, instead of using database management software.With this storage method,
you no longer need to purge to sustain storage. This method offers significantly higher
storage rates. Also, the capacity for alarm and event storage is only limited by disk space,
not by insertion rate.

– Traditional
The traditional setting stores alarms and events in the A2ALMDB SQL Server database.
This works well for smaller applications. Alarm and event data stored in the A2ALMDB
database can be retrieved using SQL queries. You can also use SQL Server tools, such as
Reporting Services, to query alarm and event history.
d. Under Network, accept the default ports or change these settings. The ports you specify are
added to the exclusions list of Windows Firewall.
– Hi storian TCP port is used for replication data.
If you are configuring a tiered historian server, specify the port number for tag replication
between the tier-1 and tier-2 servers. You must use the same port for all the tier-1 and tier-2
systems working together in the tiered configuration.
– InSight/REST TCP port is used for data queries via InSight or the Historian RES T AP I to
the Historian Server.
Type the number for the port used by InSight and RES T interface queries.
– Search port is used for data searches. This field is for reference only.
e. Under Security, Check the box if you want to allow remote access of this server's System
Management Console (SMC).
When you check Allow Remote Acce ss for SMC, Historian allows remote connection to the
SMC. Specifically, this allows remote launch and remote activation permissions for the
aahCfgS vc and aahE ventS vc Historian COM services. (By default, these are set to local launch
and local activation. ) The permissions are limited to the aaAdministrators, aaPowerUsers, and
aaUs ers groups. Anyone who is not a member of thes e groups on the server will not see that
Historian remotely via SMC.
3. In the left pane, click Security. Configure the security options as follows.
a. Under Hi storian Users, review the existing users and roles for this server. Make adjustments to
the list as needed:

– To create a new user account, click Create Users and then specify account details.
– To add existing user accounts to this list, click Add Users and then select the account
criteria to use.
– If you don't need this account anymore, mark the Delete Account check box.
b. Under SQL Logins, do one of the following to ensure your SQL Server logins are secure:
– If you want to keep using a default account listed, type a new password.
– If you don't need this account, mark the Delete Account check box.
Note: Secure Development Lifecycle (SDL) guidelines recommend against using automatical ly
created users like aaUser and aaAdminUser with well-known or publicly documented
passwords.
When you migrate from an older version of the Historian Server, this area is populated with all
preexisting SQL Server accounts and gives you the option to cha nge account password and to
delete unused accounts to ensure strong security for your system.
4. In the left pane, click Search. Then configure the search options as follows.
Under Search Configuration, specify file loc ations.

o Data Path
Accept the default path, or click the ellipsis button to specify a different directory for t he historian
history blocks.
Make sure that you have plenty of space on this drive most of your plant data will be stored here.
(The SQL Server database files typically take less disk space.)
o Log Path
Accept the default path, or click the ellipsis button to specify a different directory for the log files.
o Mark the Reindex Search Documents check box to create a new index of all existing tags.

5. In the left pane, click Reporting. Then mark the appropriate check boxes to configure OData
extensions for SQL Reporting Studio or Visual Studio Report Designer on your system.
6. In the Configuration Message s area, read messages regarding prerequisite checks, current
configuration state, and configuration activities that are logged.
7. Click Configure. The Proc essing SQL Script dialog box appears. You can see the historian
database configuration scripts running. Multiple scripts run during the configuration.
8. After the system finishes running the SQL scripts, the Historian node and Historian Server node are
shown with a green status indicator if the databas e is successfully configured.
9. Click All Messages to see all the configuration messages.
Configuring the InTouch Web Client

The InTouch Web Client is installed whenever the InTouc h run-time component is installed on a node,
and lets users view InTouch HMI applications in a web browser.
Note: If a System Management Server is configured, the InTouch Web Client will use the security
certificate and utilize the HTTPS protocol for secure communications. See Configuring the System
Management Server on page 34 for additional information.

To configure the InTouch Web Client

1. In the Configurator, select InTouch Web Client Acce ss.
2. Under Graphic Refre sh Rate, set the screen refresh interval. This determines how frequently the
web browser will query the web server for graphic data. A longer interval reduces network traffic and
may be needed for very low-bandwidth networks or intermittent connections.
 Default: 1000 ms (1 second)
 Minimum: 250 ms
 Maximum: 60000 ms (60 seconds)
Note: The Graphic Refresh Rate cannot be less than the Alarm Refresh Rate. If you lengthen the
Graphic Refresh Rate, the Alarm Refresh Rate will automatically synchronize with the Graphic
Refresh Rat e.
3. Under Alarm Refresh Rate, set the alarm refresh interval. This det ermines how frequently the web
browser will query the web server for alarm data. By default, the Alarm Refresh Rate is the same as
the Graphic Refresh rate. You can make the refres h interval longer for alarms than for graphics, but
the Alarm Refres h Rate cannot be shorter than the Graphic Refresh Rat e. A longer interval may be
needed for very low-bandwidth net works or int ermittent connections.
 Default: 1000 ms (1 second)
 Minimum: Graphic Refresh Rat e
 Maximum: 60000 ms (60 seconds)

on page 49.
System Restart after Configuration

When you have configured all the listed components, click Close. The system will prompt you to restart.
You can restart now or later.
Note: The installed programs may not function properly until you restart the system.
After the system restarts, and before you start using System Plat form, make sure that you have activated
your product licenses. See License Installation and Activation.
Installing InTouch Access Anywhere

InTouch Access Anywhere does not allow you to remotely install it. Therefore, you must run the
installation program loc ally for each instance.
Three InTouch Access Anywhere installation options are available from the System Platform
product-based installation menu. Thes e can be installed separat ely or toget her.
 Install InTouch Access Anywhere S erver on page 50
 Secure Gateway Installation on page 51
 Install the Secure Gateway and Aut hentication Server Separately or Together on page 52
See the following documents for for additional information, including configuration steps that should be
performed prior to installation. These documents are located on the Syst em Platform Installation DV D
under InstallFiles\CD-Int ouch\UserDocs.
 InTouch Access Anywhere Secure Gat eway Administrator Manual (file name:
ITAA_Server_AdminManual.pdf)
 InTouch Access Server Administrator Manual (file name: ITAA_Gateway_A dminManual.pdf)
Before installing the InTouch Access Anywhere server, verify the following requirements have been met:
 The computer that will host the InTouch Access Anywhere server must be running a 64 -bit version of
Windows 2012 or 2016.
o Windows 2012 Data Center
o Windows 2012 R2 Data Center and Standard
o Windows 2016 Data Center and Standard
Note: Embedded operating systems are not supported by InTouc h Access Anywhere Server.
 .NET Framework 4.7.1 or later must be installed on the computer that will host the InTouc h Access
Anywhere server. You can allow the setup program to install it automatically if it is not present. See
System Platform Prerequisites on page 14 for detailed information.

 InTouch applications must be built with version 10. 6 or later to be viewed through InTouch Access
Anywhere
 The InTouch Access Anywhere server must be installed on the same computer that hosts InTouch
WindowViewer.
 Remote Desktop Servic es must be configured on the host computer.
Important: InTouch Access Anywhere leverages RDP and translates RDP to WebSockets. RDS
access must be enabled on the comput er hosting InTouch Access Anywhere.
 Make sure the anticipat ed users of InTouch Access Anywhere are members of the Remote Desktop
Users group to be grant ed the right to log on to the Access Anywhere server remot ely.
 The host computer’s firewall is configured to permit inbound and outbound network traffic on port
8080.
Make sure no other application installed on the InTouch Access Anywhere server also uses port
8080.
 On host comput ers running Windows Server 2012, the InTouch WindowViewer executable file
(view.exe) must be added to the host comput er’s RemoteApp list and configured to support
command-line arguments.
 The corresponding TSE (RDS ) Concurrent license is activat ed on the host comput er.
 If upgrading to a newer version of InTouc h Access Anywhere, first back up any custom components
of the existing installation, then uninstall the existing version before installing the new version.
 InTouch Access Anywhere Server cannot be installed on computers in whic h the host name contains
non-English characters.
 InTouch applications cannot be listed by InTouch Access Anywhere if application names or folder
paths contain an ampers and (& ) character.
Install InTouch Access Anywhere Server

A basic installation of the InTouch Access Anywhere Server usually takes about five minutes. When you
select the InTouch Access Anywhere Server, several InTouc h run-time and complementary components
are auto-selected. Thes e are required for installation with the InTouch Access Anywhere Server, and
include:
 Insight Publisher
 InTouch Runtime
 InTouch Alarm DB Logger (Alarm Logger and Purge Archive components)
 InTouch Supplement ary Components (Recipe Manager, SQL Access, and Symbol Factory)
Make sure that all installation prerequisites have been met before starting the installation procedure. The
following procedure explains the basic steps to install the InTouch Access Anywhere Server on a
computer running a support ed version of Windows Server.
Before placing InTouch Access Anywhere into a secure, production environment, you may want to do
some internal testing. Install All Components on a Single Server on page 54 describes an alternative
installation method to place the InTouch Access Anywhere Server, the Secure Gateway, and the
Authentication Server on a single server computer.

To install InTouch Access Anywhere Server

1. Log on as a Windows administrator on the computer where you are installing InTouch Access
Anywhere Server.
2. Insert the System Platform DVD in your computer and run setup.exe.
3. Select Product-Ba sed Selection.
4. Select InTouch Acce ss Anywhere Server. You will see the additional components auto -selected.
Click Next to continue.
5. Click Next on the dialog box that shows the components to be installed.
6. Select the check box that acknowledges you have read and accepted the terms of the license
agreement and select Agree.
7. Click Install to begin installing InTouch Access Anywhere and InTouch Runtime.
8. A horizontal bar shows the progress of the installation.
9. Click Finish to complet e the installation.
10. Configure (or disable) the Windows Firewall for use with InTouch Access Anywhere. For details, see
Configuring a Firewall Program Exception in the InTouch Access Server Administrator Manual.
Secure Gateway Installation

This section describes the procedure to install the Secure Gateway on a computer running a supported
version of Windows server. The Secure Gateway supports other installation configurations. For more
information, see Other Secure Gateway Installation Configurations in the InTouch Access Anywhere
Secure Gateway Administrator Manual.
After verifying all installation prerequisites, start the installation procedure.

Note: Secure Gateway cannot be upgraded by installing a newer version on a computer hosting an
existing version. The existing version of Secure Gateway must be uninstalled first before attempting to
install another version on the same computer. To uninstall Sec ure Gateway, see Uninstall a Wonderware
System Platform Component (see "Uninstall a System Platform Component" on page 57).
To install InTouch Access Anywhere Secure Gateway

3. Select InTouch Acce ss Anywhere Secure Gateway, then click Next.
4. A checkbox appears that lets you customize installation. Select this if you wish to change the default
installation folder.
Otherwise, the Secure Gat eway is installed to the default installation folder, C: \Program Files (x86).
5. Accept the license agreement by selecting the I have read and accept the terms of the license
agreement option, and then click Agree.
The Ready to Install the Application screen appears.
6. Review the installation details and click Install.
7. Click Finish after the installer indicates that the Installation has completed succe ssfully.
Install the Secure Gateway and Authentication Server Separately or

Together
The Authentication Server provides an additional layer of security by authenticating end -users before
they can contact the Access Anywhere server. When the Authentication Server is enabled, only domain
users will be able to authenticate. Local system users (such as Administrator) will not be able to logon
through the A uthentication Server. The Authentication server is an optional InTouch Access Anywhere
component and is disabled by default.

The Secure Gat eway and Authentication servers can be installed separately or together on one of the
supported Windows Server operating systems, or on a Windows workstation running 32-bit or 64-bit
versions of Windows 10 Professional or Enterprise, Build 1607 and later. Follow these requirements
when installing the Authentication server:
 The Authentication Server must be installed on a computer that is a member of the domain that it will
use to authenticate users.
 The Authentication server can only be configured for one domain at a time.
 The Authentication server should be installed on the safe side of a firewall rather than the DMZ for
best security practice.
To install the Secure Gateway and Authentication server on the same or separate
computers
1. Log on as a Windows administrator of the computer that will host either the Secure Gateway, the
Authentication server, or both.
4. Determine how you want to install the Secure Gateway and the Authentication server.
Install the Secure Gateway and the Authentication server on separate computers
o Install the Secure Gateway by following the steps described in Secure Gateway Installation on
page 51. The Authentication server must be configured by setting options from the Secure
Gateway Configuration portal.
o Install the Authentication server on another computer that meets the requirements listed above
this procedure.
Install the Secure Gateway and the Authentication server together on the same computer
o Select the Secure Gateway and Authentication server options from the installation dialog box
and following the installation instructions.

5. After installing the Authentication server and the Secure Gateway, see the section, Built-In
Authenti cation Server, in the InTouch Access Anywhere S ecure Gateway A dministrat or Manual for
descriptions of the options to configure the Secure Gateway to work with an Authentication server.
Install All Components on a Single Server

All InTouch Access Anywhere server components can be installed on a single computer running a
supported version of Windows server. The Secure Gateway, the Authentication server, and the InTouch
Access Anywhere server can be installed simultaneously.
To install all InTouch Access Anywhere Components on a single server
1. Log on as a Windows administrator on the computer where you are installing InTouch Access
Anywhere.
3. Select Product-Ba sed Selection and select the checkbox for each of the three InTouc h Access
Anywhere installation options:
 Install InTouch Access Anywhere S erver on page 50
 Secure Gateway Installation on page 51
 Install the Secure Gateway and Aut hentication Server Separately or Together on page 52
4. Click Next on the dialog box that shows all components have been select to be installed.
5. Select the check box that acknowledges you have read and accepted the terms of the license
agreement and select Agree.
6. Click Install to begin installing the InTouch Access Anywhere components.
A horizontal bar shows the progress of the installation.
7. Click Finish to complet e the installation.

Modifying an Installation
You can change the System Platform components installed on your computer. You can add new
components or remove the existing ones. You can modify any component of System Platform.
You must have the installation DV D insert ed in the DVD -ROM drive before you can modify a program.
To modify an installation
1. Select the Modify option from the System Platform Modi fy, Repair or Remove Installation dialog
box. You can open the dialog by doing either of the following:
 Run Set up.exe from the System Platform installation DVD.
 Navigate to Uninstall or Change a Program in the Windows Control Panel. Then, select any
System Platform component and then click the Uninstall/Change button.
Note: The name of the Uninstall/Change option may vary depending on which Windows
operating system is installed on your computer.

2. Click the Modify option, and then click Next. The list of System Platform components appears.
3. Select or clear the components that you want to add or remove, and then click Next. The verify
change dialog box appears.
4. Click Modify. The selected components are added or removed. If the added components require
configuration, the Configurator opens. If not, the complete modification dialog box appears. See
Configuring System Platform Components on page 32 for information about the Configurator.
5. Click Finish.
Note: The system may not prompt you to restart the system after Modify is successful. However, if
you have added a new product or feature, a system restart is recommended.
Repairing an Installation
You can repair the installation of any System Platform component to fix missing or corrupt files, registry
keys or shortcuts. You can also reset the registry key to the default value.
Note: You must insert the installer DVD in the DVD -ROM drive before you can repair a program.
To repair an installation
1. Click the Uninstall or Change a Program option in Windows Control Panel. The list of software
installed on your computer appears.
2. Select the System Platform component that you want to repair, and then click the Uninstall/Change
button. The Modify Repair or Remove Installation dialog box appears.
Note: The name of the Uninstall/Change button varies depending on the Windows operating
system installed on your computer.
3. Click the Repair option, and then click Next. The Confirm Repair dialog box appears.
4. Click Repair. The complete repair dialog box appears.
5. Click Finish.

Uninstalling System Platform

Uninstall a System Platform Component
You can uninstall any System Platform component that is installed on your computer.
To uninstall a System Platform component
1. Click the Uninstall or Change a Program option in Windows Control Panel. The list of software
installed on your computer appears.
2. Select the System Platform component that you want to uninstall, and then click the
Uninstall/Change button. The Modify, Repair or Remove Installation dialog box appears.
3. Click the Remove option, and then click Next. The confirmation dialog box appears.
4. Click Uninstall. The component is uninstalled and the complete uninstallation dialog box appears.
5. Click Finish.
Uninstall All Components

To uninstall System Platform (remove all components)
Begin by opening the Windows Control Panel, and select Programs and Features. Uninstall
components by selecting the component, and then click Uninstall. You must uninstall components in the
following order:
Note: Ignore components that are listed below if they have not been installed on your system.
1. Application Server 2017 Update 3 SP1

2. InTouch 2017 2017 Update 3 SP1
3. Historian 2017 2017 Update 3 SP1
4. Historian Client 2017 Updat e 3 SP1

5. Wonderware Operations Int egration – Core (G-2. 2 Series )

6. Wonderware Operations Int egration – Supervisory Gateway (G-2.1 Series)
7. ArchestrA Service Bus Framework 4.3
8. AVEVA Enterprise License Manager
9. AVEVA Enterprise License Server
10. AVEVA Enterprise Licensing
11. AVEVA Enterprise Licensing (x86)
Upgrading System Platform

You can upgrade to System Platform 2017 Update 3 SP1 from the following prior versions:
 System Platform 2017 Update 3
 System Platform 2017
 System Platform 2014 R2 SP1 (with or without Patch 01 or Patch 02)
Only components that were previously installed can be upgraded. You cannot choose to add
components that were not already installed, and you cannot deselect components. That is, if a newer
version of a component is included on the installation DV D, the pre viously installed component is
automatically upgraded.
Important Upgrade Information
 .NET Framework: System Platform 2017 Update 3 SP1 requires .NET Framework 4.7.2. If your
system does not have this version or a newer version installed, the .NET Framewo rk will be installed
prior to product installation. A restart may be required, after which setup.exe will resume
automatically. See System Platform Prerequisites on page 14 for additional information.
 Licensing Change: If you are upgrading from Wonderware System Platform 2014R2 SP1, you will
be changing to the new licensing system. Since the License Server is a new component, it is not
added during the upgrade process. Upgrade the Galaxy Repository node first, and then use the
Modify work flow to add the License Server after the node has been upgraded. See License
Installation and Activation for additional information.
Only one License Server is required.
Note: The Galaxy Repository node is the default installation location for the License Server. You
can, however, select a different node, or install the License Server on a standalone node, depending
on your system size and archit ecture.
 Sentinel Manager: Sentinel is related to the new licensing system. The Sentinel Manager monitors
License Server and provides email notification of its status, while the Sentinel Agent monitors the
connection between each System Platform node and the License Server. The Sentinel Manager is a
new component and is not automatically added during the upgrade process. To add the Sentinel
Manager, upgrade the Galaxy Repository node first, and then use the Modi fy work flow to add the
Sentinel Manager when the upgrade completes. The Sentinel Agent is automatically added to each
upgraded node. Configure the S entinel Agent on each remote node to point to the Sentinel Manager.
See Sentinel Manager and Agent Installation on page 9 for additional information.
Only one Sentinel Manager is required.

 InTouch Acce ss Anywhere: If you plan to upgrade Wonderware System Platform on a computer
that has InTouch Access Anywhere Server or InTouc h Access Anywhere Gateway installed, you
must first uninstall the InTouch Access Anywhere Server or Gateway. Then, upgrade Wonderware
System Platform and finally, reinstall InTouch Access Anywhere.
 Machine Trust: System Platform Update3 includes the System Management Server, a new s ecurity
component that must be configured for all upgraded nodes to allow secure communications and
single sign-on (SS O). There should be only one System Management Server in your System
Platform topology, and every node should be configured to point to it. The System Management
Server is automatically added to the GR node. See Configuring the System Management Server on
page 34 for additional information. If some nodes will not be upgraded, communication with
non-upgraded nodes will continue to us e legacy communication protocols.
In multi-galaxy environments, configure only one GR node as the System Management Server, and
configure the other nodes to point to it.
About the Modify Workflow
The upgrade process can only upgrade System Platform components that are already installed on your
system. Since upgrading may introduc e new components that were not part of prior releases, you need
to run setup. exe and launc h the Modify option to install new components that are new in this release of
System Platform. New components that you may need to install through the Modify option include:
 Sentinel Manager
 License Server
To add new components through the Modify option
1. Upgrade the node and configure it.
2. Run the installation program again from the installation DVD (setup.exe).
3. Select the Modify option.
4. Select the component(s ) you want to install.
To upgrade a System Platform component
1. Insert the DVD into your DVD-ROM drive. Run setup.exe to start the set-up program. The startup
screen appears, followed by the upgrade feature dialog box that lists any prerequisites and products
to be upgraded. If new version of the .NE T Framework is required, it is installed first and then setup
resumes after a restart.
Note: You c an only upgrade the products that are already installed, and you will not be able to install
additional products during the upgrade process.
2. Click OK to proc eed, then wait for configuration to complete. If there are any recommended steps
that should be performed before continuing, they will be displayed.

3. Follow the instructions given and click Next. A list of all System Platform components appears. The
installed components that need to be upgraded are selected and disabled. You cannot clear these
check boxes or select more components during the upgrade.
4. Click Next. You may get a message to stop one or more running processes or services before
proceeding, such as the ArchestrA Watchdog Service. If this occurs, follow the on -screen
instructions, then click Retry. The upgrade dialog box appears.

5. Click Upgrade to proceed with the upgrade. The progress bar appears.
6. After the installation is over, the installation completed dialog box appears.
 Select View Readme for important information about System Platform 2017 Update 3 SP1,
including hardware and soft ware requirements, new features, and known and resolved issues .
 Select Configure to continue. You may see a Cybersecurity Notice.
For information on removing MSMXML 4.0, see the Microsoft Support web page:
https://support.microsoft.com/en-us/help/925672/ms06-061-security-update-for-microsoft-xml-c
ore-services-4-0-sp2
7. GR Node Upgrade: Always upgrade the GR node first. After upgrading the GR node, configure
licensing, ASB Security, and any other installed features that require configuration E XCEP T the
ArchestrA Service Bus. When you upgrade the GR node, a new ASB security framework is added.
This framework includes the AS B Management Server, which requires configuration. It is listed
under Arche strA Service Bus > Machine Setup in the Configurator. Do not attempt to configure
the ArchestrA Service Bus until you have run the Modify work flow. See Upgrading a Galaxy
Repository Node on page 76 for more information.

IDE and Run-Time Node Upgrade: Upgrade remote IDE nodes after upgrading the GR node, and
then upgrade run-time nodes. If you are upgrading either an IDE node or a run-time node, use the
Configurator to configure licensing, ASB Security, and any other installed features that require
configuration. See Upgrading an IDE -only Node on page 78 and Upgrading Run-Time Nodes on
page 79 for additional information.
If you are upgrading from a prior version of Application Server, and a galaxy is deployed, the Galaxy
Patcher will start as soon as you connect to the galaxy from the Application Server IDE. Undeployed
galaxies are not patched until you connect to them.
Important: Galaxy patching may take several minut es. Do not shut down the node while the patching
operation is in progress.
If you are upgrading from System Platform 2014R2 SP1, a new icon for the Wonderware Application
Manager is installed on the desktop.
Use Application Manager to select and run deployed InTouch OMI ViewApps.

C HAPTER 2
Security and Permissions
In This Chapter
Enhanced Security for Connecting to a Galaxy ............................................................................... 63
Modifying an ArchestrA User Account ............................................................................................ 63
SQL Server Rights Requirements .................................................................................................. 64
Setting the SQL Server Security Mode ........................................................................................... 65
Restoring Required SQL Server Accounts ...................................................................................... 66
Setting the FIPS Security Policy Option .......................................................................................... 67
Enhanced Security for Connecting to a Galaxy

Users must belong to the OS group aaConfigTool s to connect to a Galaxy from the IDE. Assign users to
this group as needed through the Windows Control Panel.
Modifying an ArchestrA User Account

After you install the System Platform, you can use the Change Network Account utility to change or
recreate the ArchestrA User Account. The Change Network Account Utility is a tool to manage
credentials for node-to-node communications bet ween ArchestrA components. See ArchestrA Us er
Account on page 22 for more information. A short cut to the Change Network Account utility is created
in the Wonderware Utilities folder after you install the System Platform products.
After opening the utility, select the domain name from the drop down menu if necessary. If the domain
name does not appear on the drop down menu, enter the short domain name. Do not use the fully
qualified domain name (FQDN). For example, use "DomainName" and not "DomainName.com" or
"DomainName.local."
To run the utility from the command line, see Change the ArchestrA User Account from the CLI on page
63. You must have Administrator privileges on the computer to make changes with the Change Network
Account utility. This applies to running the utility through the GUI or from the command line.
Important: When you change or recreate the ArchestrA User Account, a system restart is required.
Close all applications and click OK to proceed.
Note: If you recreate the user account using the Change Network Account utility, the Microsoft Windows
security component on the computer can take several minutes to update this information on the
ArchestrA Galaxy Repository node. Until that occurs, the ArchestrA component may not function
properly. Restarting the Galaxy Repository node updates this information immediately.
Change the ArchestrA User Account from the CLI

You can run the Change Network Account utility from the command line by invoking aaAdminUser.exe.
If you open aaAdminUser.exe from a command prompt without any flags, it opens the Change Net work
Account GUI. If you open aaAdminUser.exe with flags, it runs from the command prompt. Any changes
require that you restart the computer to complete the change.

System Platform Installation Guide Security and Permissions
The default installed loc ation for aaAdminUser.exe is:

C:\Program Files (x86)\ Common Files\ArchestrA.
Note: As is the case for the Change Network Account utility, you must have system administrator
privileges to run aaAdminUser.exe from the command prompt.
Options you can specify with aaAdminUser.exe are:
Option Flag Example
Help /h, -h, or /? aaAdminUser.exe /h

User name -u aaAdminUser.exe -u user -p password
Account password -p aaAdminUser.exe -u user -p password
Create local account -c aaAdminUser.exe -user -p password -c
Domain account -d aaAdminUser.exe -user -p password -d example.com
Open GUI <none> When no flags are specified, the Change Network
Account utility (GUI) opens
SQL Server Rights Requirements

When you install a Galaxy Repository or Historian node, the installation process creates or modifies new
user groups, SQL Server logins, and a user account (ArchestrA User Account). These provide support
for Galaxy communications, system security, and connection to SQL Server. The new/modified SQL
Server logins used by Wonderware System Platform are:
 <NodeName>\aaAdministrators
 <NodeName>\aaGalaxyOwner
 NT AUTHORITY\SYSTEM
The ArchestrA User Account, creat ed when you installed Application Server, is required for Galaxy
operations. This account:
 Is a member of the built-in Administrators group (and thus an operating system administrat or).
 Is a member of the Wonderware System Platform aaAdministrators group.
 Has one of the following SQL Server roles:
o Has the SQL Server bulkadmin role, if Enhanced Security Mode is enabled (default).
o Has the SQL Server sysadmin role, if Legacy Security Mode is enabled.
See ArchestrA User Account on page 22 and Setting the SQL Server Security Mode on page 65 for
The automated process that creates the aaA dministrators group, ArchestrA User Account, and
aaGalaxyOwner user account also provides the rights required for operations within the GR. The
aaAdministrators group, ArchestrA User Account, and aaGalaxyOwner user account must all be present
and enabled for Galaxy operations.
Caution: aaGalaxyOwner and ASBService are reserved OS user names. aaAdministrators and
ASBSolution are res erved OS group names. Do not creat e users or groups with these names.
Note: The aaGalaxyOwner account is the owner (dbo) of all Galaxy databases in your system. It does
not have a system login.

Security and Permissions System Platform Installation Guide
 If you accidentally delete the aaAdministrators group or the ArchestrA User Account from the
Windows operating system, you can run either the Change Network Account utility or the SQL
Acce ss Configurator to restore it. You can access these utilities from the Start Menu, under the
Wonderware Utilities folder.
 If you accidentally delete the aaGalaxyOwner account from the Windows operating sys tem, you
must run the SQL Acce ss Configurator to restore it.
 If you accidentally delete the aaAdministrators group, ArchestrA User Account, or aaGalaxyOwner
from the SQL Server security logons, you must run the SQL Acce ss Configurator to restore it.
Setting the SQL Server Security Mode

If you are a SQL administrator, you can use the SQL Acce ss Configurator to set user privileges within
SQL Server for accessing and using Galaxy databases (the Galaxy Repository). A short cut to the SQL
Acce ss Configurator is created in the Wonderware Utilities folder when you install Application
Server or Hi storian.
User privileges are determined by the security mode. Two security modes are available:
 Legacy Mode. Authenticated users have the sysadmin privilege and are not restricted from any SQL
Server activity, including creating, modifying, and deleting any SQL Server dat abase.
Select this mode to ensure that users can perform all Galaxy operations. If users will frequently be
restoring Galaxies created with previous versions of Application Server, this may be the preferred
setting.
 Enhanced Security Mode. This is the default setting. This mode removes the sysadmin privilege
from Application Server users, and retains only the minimum privileges needed for normal
operations.
Select this mode for compliance with corporat e or other IT security requirements or guidelines.
If you use Enhanced Security Mode, you may be prompt ed to provide SQL sysadmin user
credentials when restoring a Galaxy that was created with an older version of Application S erver.
You do not need sysadmin credentials to restore Galaxies creat ed with the current version of
Application Server.
Enhanced Security Mode removes the SQL sysadmin role from, and adds the bulkadmin role to
the following SQL logins:
o NTAUTHORITY\SYSTEM

System Platform Installation Guide Security and Permissions
o <NodeName>aaAdminstrators (local security group that contains the ArchestrA Network User)
To change the SQL security mode with the SQL Access Configurator
WARNI NG! The SQL Acce ss Configurator automatically restarts the computer to ensure system
stability. If you press OK, you will not be able to cancel the restart.
1. Select the SQL Server security mode:

 Legacy Mode.
 Enhanced Security Mode (default).
2. Select the authentication type:
 Windows authentication.
 SQL Server authentication.
3. Provide SQL sysadmin login credentials (User Name and Password).
4. Click OK. The system will restart automatically.
5. Optional: If you selected Enhanced Security Mode, open SQL Server Management Studio and
check that the NTAUTHORITY\SYSTEM <NodeName>aaAdminstrators and do not have the
sysadmin role.
Note: The system performs a check prior to changing to Enhanced Security Mode. This is to ensure
that at least one account will exist with the SQL sysadmin privilege after the change. If the system
check determines that no accounts with the SQL sysadmin privilege will remain after changing
modes, an error message will be displayed and security will remain in Legacy Mode.
Restoring Required SQL Server Accounts

If you delete the aaA dministrat ors group, ArchestrA User Account, or the aaGalaxyOwner account,
restore them by running the SQL Acce ss Configurator. You do not have to do anything else to restore
the missing group or account. The missing group or account is created automatically when you run the
utility. Running the utility does force a system restart, however, even if you retain the same security
configuration.

Security and Permissions System Platform Installation Guide
Setting the FIPS Security Policy Option

Application S erver does not support the FIPS (Federal Information Processing Standards) sec urity policy
option in Microsoft Windows. The Federal Information Processing Standards are United States
Government standards that provide a benchmark for implementing cryptographic software. If your
system has FIPS enabled, you should disable it. The security setting for FIPS is listed under Security
Settings> Local Policies> Security Options> System cryptography, or as part of Group Policy.

C HAPTER 3
Configuring SQL Server
In This Chapter
SQL Server Requirements............................................................................................................. 69
Working with SQL Server Versions ................................................................................................ 70
Using a Non-Default Port for SQL Server ....................................................................................... 71
SQL Server Requirements

In a typical configuration, you should install Microsoft SQL Server before you install A pplication Server. It
is important to take into consideration the requirements of the different versions o f SQL Server. Follow
Microsoft installation instructions for your particular edition of SQL Server. See TechNote TN548,
available on the AVEVA Global Customer Support web site, for detailed SQL Server installation
instructions. While TechNote TN548 describ es the installation process for SQL Server 2012, the
installation process is similar for ot her versions of SQL Server.
If no version of SQL Server is installed on your system when you install System Platform, and you install
a product or role that includes either Historian Server or an ArchestrA Galaxy Repository, you can
choose to allow System Platform to automatically install SQL Server 2014 Express SP2 with Tools as it
installs other prerequisites.
Note: SQL S erver Express is limited for use with small installations only (25,000 I/O per node or less).
For information about the versions of SQL Server supported by Application Server and other System
Platform products, see the System Platform Readme.
For more information about specific requirements for SQL Server configuration, see SQL Server Rights
Requirements on page 64, or see Microsoft document ation available online.
 A support ed version of SQL Server must be installed on the computer designated as the ArchestrA
Galaxy Repository (GR) node before you install Application S erver. If you select a product or role
that requires the Galaxy Repository, and SQL Server is not installed on the computer, the installation
program will install SQL Server 2014 Express with Tools SP2.
 You cannot install and use a GR on a computer that has both Micros oft SQL Server 2000 and
Microsoft SQL Server 2008 or later versions installed.
 The GR locks the SQL Server maximum memory usage to 65% of the computer's physical memory.
 TCP/IP must be enabled on the computer hosting a SQL Server database. The TCP/IP protoc ol
setting can be verified from the SQL Server Network Configuration under SQL Server Configuration
Manager. Do the following steps to enable TCP/IP.
To enable the TCP/IP protocol for the SQL Server database instance
1. Open the SQL Server Configuration Manager.
2. In the tree pane, click SQL Server Services.
3. If any servic es are displayed in the results pane, verify that each service under is in the Running
state.
If a service is Stopped, right-click the name of the service, and click Start.

System Platform Installation Guide Configuring SQL Server
4. In the tree pane, click SQL Server Network Configuration to expand it, and then click Protocol s
for MSSQLServer/<InstanceName>.
If you specified the default instance during installation, the instance name will be MSSQLS ERVER.
5. In the results pane, verify that each protocol is Enabled:
 Shared Memory
 Named Pipes
 TCP/IP
If Di sabled appears, right-click on the protocol name and enable it.
6. In the tree pane, click SQL Native Client Configuration to expand it, and then click Client
Protocol s.
7. In the results pane, verify that each client prot ocol is Enabled:
 Shared Memory
 Named Pipes
 TCP/IP
If Di sabled appears, right-click on the protocol name and enable it.
8. If you had to enable any services:
a. Start Task Manager.
b. Go to the Services tab.
c. Restart MSSQLServer/<InstanceName>.
Working with SQL Server Versions

The installation workflow will vary, depending on whether or not SQL Server is already installed. The
version of SQL Server that is installed can also make a difference in the workflow. If SQL Server is not
already installed, the System Platform installation program will install SQL Server Express. This is
adequate for small configurations, but not for medium and large configurations. For these, install SQL
Server before installing System Platform. The following work flow scenarios are described:
 SQL Server not found on node: small configuration
 SQL Server not found on node: medium and larger configurations
 Compatible version of SQL Server already installed
 New (untested) version of SQL Server already installed
 Incompatible version of SQL Server already installed
Note: Nodes are defined as follows: Small = up to 25,000 I/O per node; Medium = 25,000 to 50,000 I/O
per node; Large = 50,000 to 400,000 I/O per node.
SQL Server not found on node: small configuration

If you install the Application Server Galaxy Repository and SQL Server is not found on the computer,
SQL Server 2014 Express with Tools SP2 is installed as part of the installation process. This version of
SQL Server is suited for small configurations, and is best for a single -node system. You can use any of
the following versions of SQL Server Express for small installations:
 SQL Server 2012 Express SSME (SP2)
 SQL Server 2014 Express SSME (no service pack, SP1, and SP2 (default))

Configuring SQL Server System Platform Installation Guide
 SQL Server 2016 Express SSME (no service pack, SP1)

See the System Platform Readme for additional information.
SQL Server not found on node: medium and larger configurations

For medium and larger systems, the following versions of SQL Server are supported:
 SQL Server 2012 Standard or E nterprise edition (SP2)
 SQL Server 2014 Standard or E nterprise edition (no service pack, SP1, SP2)
 SQL Server 2016 Standard or E nterprise edition (no service pack, SP1)
See the System Platform Readme for additional information.
For more information about the comparative capabilities of SQL Server 2016 and earlier versions, see
the following URL:
https://msdn.microsoft.com/en-us/library/mt590198(v=s ql.1).aspx
Compatible version of SQL Server already installed

If a compatible version of SQL Server is already installed, System Platform installation will continue
without interruption (SQL Server Express 2014 SP2 is not installed).
New version of SQL Server already installed

If a new version of SQL Server is already installed that has not yet been fully tested with System Platform
2017 Update 3 SP1 products, a warning is displayed stating that the installed SQL version has not yet
been tested. You can proceed with the installation, but we recommend that you contact AVEVA Global
Customer Support before proceeding to check if any issues have been found.
Incompatible version of SQL Server already installed

If an older version of SQL Server is already installed that is not supported with the current version of
System Platform products, installation will stop and a warning will be displayed stating the SQL Server
version is not compatible. You must upgrade to a supported version of SQL Server before you can
resume installation.
Using a Non-Default Port for SQL Server

The default port for SQL Server is 1433. If you want to use a different port number, use SQL Server
Configuration Manager to set the port number.
If you are using t he SQLData object to store and retrieve data, you will need to enter the non -default SQL
Server port number as you ent er other database connection information. See the SQLData Object help
file, available through the ArchestrA IDE, for additional information.
To change to a non-default SQL Server port number
1. If you are upgrading from a prior version of System Platform, upgrade all nodes. See Basic Upgrade
Sequence on page 76 for more information. If this is a new installation, continue to step 2.
2. Launch SQL Server Configuration Manager.
3. Select SQL Server Network Configuration, then select Protocol s for MSSQLS ERV ER.

System Platform Installation Guide Configuring SQL Server
4. In the list of protocol names to the right, select and open TCP/IP Properties.
5. In the TCP/IP Addre sse s tab, scroll down to IPAll.
6. Change the TCP Port number from 1433 to the desired number.
7. Click OK or Apply to commit the changes.
8. Reboot the GR node.
Setting a Windows Firewall Exception for the SQL Server Port

You will need to set a Windows Firewall exception for a non -default SQL Server port number if you are
using a remote node. Without access through the firewall, remote nodes will be unable to connect to the
database.
To allow access through the Windows Firewall
1. Open Allow an app through Windows Firewall.
2. Select SQLServer from the list of applications. Double click to open the Edit a Port window.
3. Change the port number to match the port number listed in SQL Server Configuration Manager.
4. Click Network type s... and select Domain.

C HAPTER 4
Application Server Upgrade
Direct upgrade to Application Server 2017 Update 3 SP1 is supported from:
 Application Server 2017 Update 3
 Application Server 2017
 Application Server 2014 R2 SP1 Patch 02 (Patch 01 was for Historian)
 Application Server 2014 R2 SP1
In This Chapter
About Upgrading Application Server............................................................................................... 73
Basic Upgrade S equence .............................................................................................................. 76
Upgrading a Galaxy Repository Node ............................................................................................ 76
Upgrading an IDE-only Node ......................................................................................................... 78
Migrating the Galaxy Database ...................................................................................................... 78
Upgrading Run-Time Nodes .......................................................................................................... 79
Upgrading Redundant Pairs .......................................................................................................... 80
Upgrade Considerations for Multi-Galaxy Communication ............................................................... 84
Issues with Legacy Common Components ..................................................................................... 84
About Upgrading Application Server

Important: Direct upgrade to Application Server 2017 Update 3 SP1 is supported from Application
Server 2014 R2 SP1 (with or without Patch 02), Applic ation Server 2017, Application Server 2017
Update 1, Update 2, and Update 3. Your system must meet the minimum system requirements, including
operating system version, SQL Server version, and .NE T Framework version. Users must belong to the
OS group aaConfigTool s to connect to a Galaxy from the IDE. Assign users to this group as needed
through the Window s Control Panel.
Important Upgrade Information

 .NET Framework: System Platform 2017 Update 3 SP1 requires .NET Framework 4.7.2. If your
system does not have this version or a newer version installed, the .NET Framework will be installed
prior to product installation. A restart may be required, after which setup.exe will resume
automatically. See System Platform Prerequisites on page 14 for additional information.
 Licensing Change: If you are upgrading from Wonderware System Platform 2014R2 SP1, you will
be changing to the new licensing system. Since the License Server is a new component, it is not
added during the upgrade process. Upgrade the Galaxy Repository node first, and then use the
Modify work flow to add the License Server after the node has been upgraded. See License
Installation and Activation for additional information.
Only one License Server is required.

System Platform Installation Guide Application Server Upgrade
Note: The Galaxy Repository node is the default installation location for the License Server. You
can, however, select a different node, or install the License Server on a standalone node, depending
on your system size and archit ecture.
 Sentinel Manager: Sentinel is related to the new licensing system. The Sentinel Manager monitors
License Server and provides email notification of its status, while the Sentinel Agent monitors the
connection between each System Platform node and the Licens e Server. The Sentinel Manager is a
new component and is not automatically added during the upgrade process. To add the Sentinel
Manager, upgrade the Galaxy Repository node first, and then use the Modi fy work flow to add the
Sentinel Manager when the upgrade completes. The Sentinel Agent is automatically added to each
upgraded node. Configure the S entinel Agent on each remote node to point to the Sentinel Manager.
See Sentinel Manager and Agent Installation on page 9 for additional information.
Only one Sentinel Manager is required.
 InTouch Acce ss Anywhere: If you plan to upgrade Wonderware System Platform on a computer
that has InTouch Access Anywhere Server or InTouc h Access Anywhere Gateway installed, you
must first uninstall the InTouch Access Anywhere Server or Gateway. Then, upgrade Wonderware
System Platform and finally, reinstall InTouch Access Anywhere.
 Machine Trust: System Platform Update3 includes the System Management Server, a new s ecurity
component that must be configured for all upgraded nodes to allow secure communications and
single sign-on (SS O). There should be only one System Management Server in your System
Platform topology, and every node should be configured to point to it. The System Management
Server is automatically added to the GR node. See Configuring the System Management Server on
page 34 for additional information. If some nodes will not be upgraded, communication with
non-upgraded nodes will continue to us e legacy communication protocols.
In multi-galaxy environments, configure only one GR node as the System Management Server, and
About the Modify Workflow
The upgrade process can only upgrade System Platform components that are already installed on your
system. Since upgrading may introduc e new components that were not part of prior releases, you need
to run setup. exe and launc h the Modify option to install new components that are new in this release of
System Platform. New components that you may need to install through the Modify option include:
 Sentinel Manager
 License Server
To add new components through the Modify option
1. Upgrade the node and configure it.
2. Run the installation program again from the installation DVD (setup.exe).
3. Select the Modify option.
4. Select the component(s ) you want to install.
If you plan to upgrade system components in addition to Application Server, keep the following in mind:
 After Application Server is installed, operating system migration is not supported, with the following
upgrade exceptions:
o Windows 8 to Windows 8.1
o Windows 8.1 to Windows 10
o Windows Server 2012 to Windows Server 2012 R2
Other than the above exceptions, System Platform products must be uninstalled prior to upgrading
the operating system.

Application Server Upgrade System Platform Installation Guide
 You can upgrade SQL Server after Application Server is installed. Refer to Microsoft’s SQL Server
resources for guidelines and procedures.
To upgrade SQL Server aft er Application Server is installed, we recommend that you undeploy any
galaxies deployed on the relevant comput er, and that you undeploy all ArchestrA Service Bus (ASB)
services. For more information, see the Application Server User Guide.
You can upgrade the following Application Server components:
 Bootstrap
You will see a warning message if you attempt to upgrade a comput er with a deployed WinPlatform.
You have the choice to continue with the upgrade or to cancel. If you continue with the Bootstrap
upgrade, the deployed WinPlatform object is removed from run time and upgraded.
If an InTouchViewApp instance is deployed for a managed InTouch application, the folder is
undeploy ed and deleted. You are prompted to stop InTouch WindowViewer from running the
managed application.
 IDE and Bootstrap
You will see a warning message if you attempt to upgrade a comput er with a deployed WinPlatform.
You have the choice to continue with the upgrade or to cancel. If you continue with the upgrade, the
current IDE and Bootstrap are removed and the new versions are installed.
If an installed InTouchViewApp instance is deploy ed for a managed InTouch application, the folder is
undeploy ed and deleted. You are prompted to stop InTouch WindowViewer from running the
managed application.
 Galaxy Repository (GR) and Bootstrap
You will see a warning message if you attempt to upgrade a computer with a deployed WinPl atform
or a client application is connected to the GR node. You can choose to continue wit h the upgrade or
to cancel. If you continue, the components are removed and upgraded.
Upgraded IDE/Client nodes cannot connect to a non-upgraded GR node. The GR node is
undeploy ed before it is upgraded.
 IDE, GR, and Bootstrap
A warning message is displayed if you attempt to upgrade a computer with a deployed WinPlatform
or if a client application is connected to the GR node. You can choose to continue with the upgrad e or
to cancel. If you continue, all components are removed and upgraded.
 Run-time node
Upgrading the Bootstrap on any comput er removes the running WinPlat form and AppEngine. Both of
these system objects are marked as undeployed if they are running on any Galaxy node.
Note: No system objects are removed on non-GR nodes when migrating from earlier versions of
Application Server.
If a remote node is disconnected from the GR node, or if you upgrade the remot e node before you
upgrade the GR node, the remote Plat form is not marked as undeployed. You must undeploy and
redeploy the Platform.
The run-time functionality of Application Server continues throughout the upgrade process, except
during a run-time node upgrade. Configuration, however, must be done using components that are at the
same version level. For example, you cannot use the Galaxy Brows er in the InTouch HMI on a
non-upgraded node to view or select attributes from an upgraded Galaxy. You can, though, view or
modify run-time dat a using an InTouch window or the Object Viewer.
Special considerations apply if you are upgrading both the Application Server and the Historian. For
more information, see Upgrading from a Previous Version on page 125.

Basic Upgrade Sequence

Important: Back up the Galaxy before starting an upgrade. Also, upload any run-time changes for critical
objects. You cannot upload any run -time change from non-upgraded nodes after you upgrade the
system.
.NET 4.7.2 is installed if it or a later version is not already present. You will be prompted to restart your
computer aft er the .NE T framework is installed.
The basic upgrade steps are:
1. Upgrade your hardware and prerequisite software such as the operating system or Microsoft
SQL Server to the required versions. For information on hardware and soft ware requirements, see
the System Platform Readme file.
If you are upgrading the SQL Server database on the GR node, you must undeploy the GR node
before starting the SQL Server upgrade.
2. Upgrade and configure the GR node. To add the ASB Management S erver to the GR node, do not
Configure ASB Security at this time. Run Setup.exe after upgrading the node and use the Modify
option to add the Management Server, then configure ASB Security. For more information, see
Upgrading a Galaxy Repository Node on page 76.
3. Upgrade and configure at least one IDE installation. If you upgrade the GR node, that IDE
installation is upgraded. However, if you have any IDE-only nodes, you will have to upgrade them
separately. For more information, see Upgrading an I DE-only Node on page 78.
4. Migrate the Galaxy database. Connect to the upgraded GR node from the upgraded IDE to migrate
the galaxy to the new version automatically.
5. Deploy the GR Platform.
6. Upgrade and configure run-time nodes.
 Upgrade non-redundant run-time nodes one at a time and redeploy them. For more information,
see Upgrading Run-Time Nodes on page 79.
 Upgrade redundant pairs one at a time. For more information, see Upgrading Redundant Pairs
on page 80.
If you upgrade a remote Platform node before you migrate the Galaxy database, the remot e Platform and
hosted objects show the software upgrade pending icon after you migrate and deploy the Galaxy. To
resolve this, undeploy and redeploy the remote Plat form.
Important: After you have upgraded the GR node to Application Server 2017 Update 3 SP1, you will not
be able to deploy or undeploy from the GR node to non-upgraded remote nodes. Also, an IDE node that
has been upgraded will not be able to connect to a GR node that has not been upgraded.
Note: As long as the operating system and SQL requirements are met, upgrade is supported. During
software installation, operating system upgrade is not supported.
Upgrading a Galaxy Repository Node

Important: Upgrade the GR node before upgrading other nodes.
When you upgrade a GR node, the local Platform and all hosted objects are undeployed and the
database schema is migrated from the existing schema to the Application Server 2017 Update 3 SP1
schema. Existing data from the GR is also migrat ed to the new schema.
You must upgrade all Application Server components (IDE, Bootstrap, and GR) to the same version that
are installed on the GR node.

SQL Server Considerations

If the GR node contains less than the recomm ended RAM amount, system performance may be
impacted as SQL Server will use more CPU t o compensate for the lower amount of available memory. To
improve system performance, set the SQL Server minimum memory (min server memory) to 1/3 of total
physical memory. See the Application S erver User Guide, "Allocating Galaxy Repository Node Memory,"
for additional information.
To upgrade the GR node
1. Review the status of objects deploy ed in the system and take appropriate action, if needed.
2. Run Setup.exe from the DVD. See Upgrading System Platform on page 58 for information about the
installation process.
3. When the Installation Complete dialog box appears, click Configure to continue.
4. Configuration: Configure licensing and other installed features, such as the Historian and the
InTouch Web Client. Do NOT configure the ArchestrA Service Bus at this time. You must add an
ASB Management Server to the node before configuring the A rchestrA Service Bus.
Important: In multi-galaxy environments, add a Management Server to only one GR node, and
5. Close the Configurator. When you see the prompt to restart the computer, select Restart Later.
6. Run setup.exe again. The Modify, Repair, Remove dialog box is displayed.
7. Select Modify, then click Next.
8. Select any new components that you want to add to the Galaxy Repository node, such as
 License Server
 Sentinel Manager
After making your selections, click Next.

9. When the Modify process completes, click Finish to close the Modify dialog box. The Cybers ecurity
notice may be displayed (see Upgrading System Platform on page 58, step 6).
10. From the Windows Start menu, open the Configurator.
11. Configure any new components that require configuratio n, then close the Configurator. See
Configuring System Platform Components on page 32 for additional information.
12. Follow the prompts to complete the upgrade.
13. When the GR node has been upgraded, open the IDE and connect to the galaxy. The galaxy will be
automatically migrated to System Platform 2017 Update 3 SP1.
Note: If you are using a remote IDE node to connect to the galaxy, make sure that you have
upgraded the IDE node before connecting to the galaxy.
Upgrading an IDE-only Node

Important: Upgrade the GR node before upgrading IDE-only nodes.
If you have IDE -only installations on nodes other than the GR node, you need to upgrade them
separately.
Important: An IDE node that has been upgraded will not be able to connect to a GR node that has not
been upgraded. Conversely, an IDE node that has not been upgraded cannot connect to a GR node that
has been upgraded.
To upgrade an IDE-only node

When the Installation Complete dialog box appears, click Configure to continue.
2. Configuration: Configure licensing and other installed features, such as the Historian, and the
InTouch Web Client.
 Configure the ASB Management Server point to the Management Server on the GR node. See
Configuring the S ystem Management Server on page 34 for additional information.
 Configure the Sentinel Agent to point to the Sentinel Ma nager. See Advanced Sentinel System
Configuration on page 42 for additional information.
3. When prompted, click Restart Now to complete the upgrade.
Migrating the Galaxy Database

To migrate the database:
 The IDE you use to migrate the database must be the current version.
 The GR node must already be upgraded to the current version.
Make sure that all connections to the Galaxy database are closed before migrating the database.
After you migrat e the Galaxy, deployed objects on a non -upgraded node are marked with pending
software upgrade status.

SQL Server Considerations

If the GR node contains less than the recommended RAM amount, system performance may be
impacted as SQL Server will use more CPU t o compensate for the lower amount of available memory. To
improve system performance, set the SQL Server minimum memory (min server memory) t o 1/3 of total
physical memory. See the Application S erver User Guide, "Allocating Galaxy Repository Node Memory,"
for additional information.
To migrate the Galaxy database
1. Start the IDE.
2. Connect to the Galaxy databas e to migrat e. You are prompted to migrate it.
3. Follow the prompts to complete the migration.
Migration errors
Migration of a very large Galaxy may fail, with various (and sometimes misleading) warnings and errors
displayed in the Logger. This is due to the Galaxy database transaction log expanding over its maximum
allocated size.
Before making the changes described here, use the E vent Viewer to check if the transaction log is full. If
you confirm that the transaction log has exceeded its maximum file size restriction, remove the restriction
as follows:
1. In SQL Server Management Studio, right click the Galaxy database, then click Properties on the
shortcut menu.
2. In the Database Properties dialog, select the Files page.
3. Locate Log ... in the File Type column.
4. Click the ellipsis (...) button in the Autogrowth column on the same line.
5. In the Change Autogrowth for Ba se_Application_Server_log dialog, click the Unrestricted File
Growth radio button under the Maximum File Size parameter, then click OK.
6. After the Galaxy migration is finished, repeat steps 1 through 5 to reinstate the file size limit on the
transaction log.
Upgrading Run-Time Nodes

Important: Upgrade the GR node and any IDE -only nodes before upgrading run-time nodes.
After you upgrade the GR and IDE, all run-time nodes continue to run. This enables you to upgrade the
run-time nodes individually when it is convenient.
Important: After you have upgraded the GR node, and you have migrated the galaxy, you will not be
able to deploy or undeploy from the GR node to remote nodes. Also, an upgraded IDE node will not be
able to connect to a GR node that has not been upgraded.
Upgrading a run-time node will remove (undeploy) any deployed Platforms from that node.
After you upgrade and then deploy a run-time node, it continues to function with other run-time nodes as
long as the ot her nodes are the current version or from the previous version.
The run-time node does not function while you are upgrading it. You cannot roll back the upgrade.
After you upgrade the run-time node and all hosted objects, you need t o redeploy the WinPlat form and all
hosted objects to the node.
The GR node migration fails if the GR node is used as a run-time node for another GR.

To upgrade a run-time node

When the Installation Complete dialog box appears, click Configure to continue.
2. Configuration: Configure licensing and other installed features, such as the Historian, and the
InTouch Web Client.
 Configure the ASB Management Server point to the Management Server on the GR node. See
Configuring the S ystem Management Server on page 34 for additional information.
 Configure the Sentinel Agent to point to the Sentinel Manager. See Advanced Sentinel System
Configuration on page 42 for additional information.
3. When prompted, click Restart Now to complete the upgrade.
Upgrading Redundant Pairs

You can reduce plant down time by upgrading the two partner nodes in a redundant pair, one at a time.
Platforms hosting redundant pairs may be deployed even when a partner platform is not the same
software version as the Galaxy Repository (GR) platform, or is in the Software Upgrade Pending (S UP)
state.
When upgrading a redundant pair, we recommend upgrading the standby partner first. This way, only
one failover of t he redundant engines is needed, thus minimizing the period of time in which process data
is not collected. After upgrading the first node, upgrade the second as soon as possible. When only one
node is upgraded, backup and failover are not available. Both nodes must be at the same software
version to enable redundancy.
The following table illustrat es the workflow for upgrading a Galaxy Repository and one redundant pair,
consisting of different nodes, from software version 1 (v1) to version 2 (v2). Action items are shaded. In
this example, the redundant pair is comprised of Node B and Node C, as a redundant Application Engine
is hosted by the platform on eac h node. Use the Plat form Manager to det ermine which plat form (P1 or
P2) is hosting the active Application Engine. See the Plat form Manager User’s Guide for additional
information.
To upgrade a redundant pair
Follow the actions listed in the table to upgrade a GR node and redundant pair. These instructions
assume an initial state where the primary engine (E 1) is active. At the conclusion of this procedure, all
three nodes are upgraded and the backup engine (E 1b) is active.
Node A Node B Node C

Galaxy Repository (GR) Primary AppE ngine (E1) Backup AppEngine (E1b)
Platform 0 (P0) Platform 1 (P1) Platform 2 (P2)
Resulting Resulting Resulting

Step Action State Action State Action State
--- (Initial state) Deployed. E1 Deployed E1b

– Active. Deployed –
Standby.



1 Upload Changes
run-time made at
changes run-time now
stored in the
database.
2 Upgrade All objects on

(with P0 become
AppServer undeploy ed.
deployed but
shut down)
3 Reboot when Software is

prompted now at v2.
4 Open IDE Galaxy

and migrate database
database now at v2.
IDE shows
P1 and P2 in
SUP state.
5 Optional: InTouch
Open and ViewApps
migrate now at v2.
InTouch
ViewApps
6 Cascade All objects on

deploy P0 P0 are
deployed.



7 Upgrade P2 and its

(with hosted
AppServer engines and
deployed but objects
shut down) become
undeploy ed.
8 Cascade E1b
Deploy P2 becomes
active;
E1 becomes Note: This hosted
undeploy ed. action results objects are
E1 shows as in a brief now running
undeploy ed, downtime for under v2.
but objects objects on
under E1 E1 and E1b Note: E1b
show as as E1 does NOT
deployed. becomes start from the
undeploy ed check-
(a few pointed state
seconds to a of non-
few minut es, upgraded
depending E1.
on number of
objects).
9 Upgrade P1 becomes
(with undeploy ed.
AppServer
deployed but
shut down)
10 Cascade E1 is No down-
deploy P1 deployed as time for
part of P1 objects on
deployment. E1b as E1b
continues to
E1 starts as
run as active.
standby and
fully syncs
with active
engine.
--- Final state Deployed. E1 Deployed E1b
– Standby. Deployed –
Active.

After you have upgraded to System Platform 2017 Updat e 3 SP 1, you can enable CPU load balancing to
improve the performance of redundant AppE ngines during failover. See the Application Server User
Guide, Working with Redundancy, for additional information.
The following table describes the behaviors associated with specific upgrade actions and states.
Action or State Behavior
Cascade deploy a Platform If the upgraded platform hosts a backup redundant engine with a
after upgrade partner in the SUP state, then during the deploy operation, it will
extract the hosted objects from the partner and deploy them
along with the backup redundant engine.
Deploy a redundant engine The deploy operation is always a Cascade Deploy.

with a partner in the SUP state.
Multi-selection for a cascade The cascade deploy operation skips the redundant engine in
deployment includes a SUP state and logs a message.
redundant engine with a
partner in S UP state
Select a backup redundant The backup redundant engine extracts the hosted objects from
partner engine for deployment the primary redundant engine and deploys them along with the
backup redundant engine.
The hosted objects are under the primary redundant engine on a
partner platform which is in S UP state. The hosted objects will be
forced to deploy with the newer software version during the
deployment of the backup redundant engine.
A dialog displays with the option to continue deployment or to
cancel.
Partner engine is deployed but Redundant engine deployment fails.

not reachable or not ready to
sync.
Partner engine has older The partner engine is detected and rec ognized as having an
software version. older soft ware version. It is automatically stopped and
unregistered.
Primary engine transitions into Active – Partner not Upgraded
redundancy status.
Primary and backup partners cannot sync, but references to a
redundant engine with this status—or with Active or Active –
Standby not Available redundancy statuses—will resolve.
Application Objects can be deployed to a redundant partner with
Acti ve – Partner Not Upgraded redundancy status.
You will not be able to deploy the partner engine until you have
upgraded it.

Upgrade Considerations for Multi-Galaxy Communication

Important: In multi-galaxy environments, add an ASB Management Server to only one GR node, and
configure the other nodes to point to it. See Configuring the System Management Server on page 34 for
Setting up a multiple galaxy environment requires a unique name for each galaxy in the environment.
This may require you to rename one or more galaxies if you plan to include galaxies with the same name
in your multi-galaxy communication environment. We recommend performing all necessary renaming
prior to upgrading System Platform. This will prepare your galaxies for use in a multi -galaxy environment
without disrupting the upgrade workflow.
Important: It is very import ant that you follow the galaxy name change procedure provided in the
following steps and in the Application Server User Guide. You must create a new galaxy with a new,
unique name, from a backup .cab file rather than creating a galaxy and performing a restore of the
backup .cab file.
For more information about creating and backing up galaxies, see "Getting Start ed with the IDE," and
"Managing Galaxies," in the Application Server User Guide.
To rename a galaxy for use in a multi-galaxy environment
1. Select a galaxy with a duplicate name, undeploy it and back it up to create a .cab file.
2. Use the .cab file as a "template" by placing it in \Program
Files\ArchestrA\Framework\Bin\BackupGalaxies.
3. Create a new galaxy with a new name, based on the backup .cab file. The name must be uni que, not
in use anywhere else in the multi-galaxy environment.
4. Repeat the preceding steps for each galaxy to be renamed with a unique name.
5. Redeploy each newly creat ed galaxy.
6. Delet e the original galaxy from the GR node.
7. Upgrade to Application Server 2017 Update 3 SP1.
Your galaxy can now be configured for use in a multi-galaxy environment.
Issues with Legacy Common Components

Application Server uses the lat est version of the ArchestrA common components, which are installed to
the following folder:
C:\Program Files\Common Files\ArchestrA
On a 64-bit operating system, the common components are installed to the following folder:
C:\Program Files (x86)\ Common Files\ArchestrA
Legacy ArchestrA common components are installed to the following folder:
C:\Program Files\FactorySuite\Common
On a 64-bit operating system, legacy common components are installed to the following folder:
C:\Program Files (x86)\FactorySuite\Common
It is possible to install duplicate common components on a computer if you install an ArchestrA product
that still uses the legacy common components after you install Application Server. Unexpected behavior
can occur if duplicate common components are installed. The system components may not run properly,
or may not run at all. Contact technical support for further assistance. You can also reference Tech Note
454, Manual Uninstall of Products.

C HAPTER 5
InTouch HMI Requirements and
Prerequisites
You need to meet the requirements and prerequisites for products.
In This Chapter
Installing OI Gateway and Upgrading from FS Gateway ................................................................. 85
Installing OI Gateway and Upgrading from FS Gateway

Operations Integration Gateway (OI Gateway) is automatically installed as an InTouch component when
InTouch is selected for installation. OI Gateway replaces Factory Suite (FS) Gateway, which was
supplied with prior versions of System Platform. Like FS Gat eway, OI Gateway acts as a
communications protocol converter, provides OPC connectivity and also supports OPC UA connectivity.
Default configurations for both OP C and OPC UA are included.
See the Operations Integration Gateway Help for information about connecting to OP C and OPC UA
servers, as well as for information about linking clients and data sources that communicate using
different protocols.
In addition to installing OI Gateway as part of installing InTouch, you can install OI Gateway as a
stand-alone application. There are three common installation scenarios:
"Clean" System Older version of OI FS Gateway is installed

without OI Gateway or Gateway is installed
FS Gateway
OI Gateway is installed The System Platform The installation program removes FS
as part of InTouc h installation program Gateway, but saves the existing FS
installation. upgrades the existing OI Gateway configuration.
Gateway version to the new
Two instances of OI Gat eway are
version and exits.
installed. The existing FS Gateway is
Restart the System Platform replaced by the second OI Gateway
installation program after OI instance, which uses the existing FS
Gateway has been Gateway application name.
upgraded.
After the upgrade to System Platform
This installs the remaining 2017 Update 3 SP1 is complete, activate
System Platform the instance that has replac ed FS
components, including Gateway.
InTouch.
There is no change in behavior for
InTouch users that use the pre-existing
OPC access name.
See Compatibility with E xisting FS
Gateway Applications on page 86.

System Platform Installation Guide InTouch HMI Requirements and Prerequisites
Compatibility with Existing FS Gateway Applications

If you are upgrading from InTouch 2014 R2 SP1 where FSGat eway has been installed, OI Gateway will
continue to maintain the FSGateway application name in the Access Name definition. The application
name is preserved to enhance compatibility with existing applications.
 If you are upgrading from InTouch 2014 R2 SP1, FS Gateway will appear in the SMC (System
Management Console) under DAManager.
 After upgrading from InTouc h 2014 R2 SP1, two new Gat eway servers are installed. The first OI
Gateway is installed under Operations Integration Supervisory Servers as OI.GA TEWAY.n. A
second instance replaces the existing FS Gateway instance, but preserves the existing configuration
and name, even though FS Gateway has been delet ed and the new OI Gat eway has been installed
in its place. Since the new gateway instance is in a deactivated state, you must activate it (select the
instance, right-click, and select "Activat e Server").

InTouch HMI Requirements and Prerequisites System Platform Installation Guide
Note that the component names are changed from "FSGateway" to "Gateway." This does not affect
references or change the behavior of the gateway.
FS Gateway Installation Scenarios

The following table shows the possible combinations for installing FS Gateway and System Platform.
See the System Platform Readme and the InTouch Readme for information about upgrading and
migrating to System Platform 2017 Update 3 SP1 with InTouch HMI 2017 Update 3 SP1 from earlier
versions of InTouch.
I have... I want to...
Install FS Gateway 3.0 SP2 Install System Platform 2017

Stand-alone Update 3 SP1 with InTouch and
FS Gateway 3.0 SP2
A clean system  FS Gateway is preconfigured  FS Gateway is preconfigured
with a predefined OPC access with a predefined OPC access
Name. Name.
 FS Gateway is installed as  FS Gateway is installed as a
stand-alone product. hidden feature.
 FS Gateway appears in  InTouch appears in
Uninstall/Change Programs. Uninstall/Change Programs.

System Platform Installation Guide InTouch HMI Requirements and Prerequisites

FS Gateway 3.0 SP2
FS Gateway 2.0.0 or  Existing FS Gateway  Existing FS Gateway
previous installed Configuration is retained. Configuration is retained.
(Stand-alone)
 FS Gateway is upgraded.  InTouch is installed.
 FS Gateway appears in  FS Gateway is installed as a
Uninstall/Change Programs. hidden feature.
 FS Gateway is upgraded.
 FS Gateway appears in
Uninstall/Change Programs.
 InTouch appears in
InTouch 10. 0.0 or  FS Gateway is preconfigured  FS Gateway is preconfigured

previous installed with a predefined OPC access with a predefined OPC access
Name. Name.
 FS Gateway is installed as  FS Gateway is installed as a
stand-alone product. hidden feature.
 FS Gateway appears in  InTouch is upgraded.
 InTouch appears in Uninstall/Change Programs.
FS Gateway 2.0.0  Existing FS Gateway  Existing FS Gateway

(Stand-alone) or Configuration is retained. Configuration is retained.
previous and
InTouch 10. 0.0 or  FS Gateway is upgraded.  FS Gateway is upgraded.
previous  FS Gateway appears in  InTouch is upgraded.
FS Gateway 2.0.1  Existing FS Gateway  Existing FS Gateway
Stand-alone Configuration is retained. Configuration is retained.
 FS Gateway is upgraded.  FS Gateway is installed as a
hidden feature.
Uninstall/Change Programs.  InTouch is installed.

InTouch HMI Requirements and Prerequisites System Platform Installation Guide

FS Gateway 3.0 SP2
System Platform  FS Gateway 2.0.1 must be  Existing FS Gateway
2012 with InTouch manually uninstalled (after Configuration is retained.
10.5 and doing this, it is equivalent to
FS Gateway 2.0.1 installing FS Gateway on a  FS Gateway is installed as a
clean system). hidden feature.
 InTouch is upgraded.
FS Gateway 3.0.0  FS Gateway is preconfigured  Existing FS Gateway
Stand-alone with a predefined OPC access Configuration is retained.
Name.
 InTouch is installed.
 FS Gateway is installed as
stand-alone product.  FS Gateway is installed as a
hidden feature.
Uninstall/Change Programs.  FS Gateway appears in
System Platform  Existing FS Gateway  Existing FS Gateway
2012 R2 with Configuration is retained. Configuration is retained.
InTouch 10. 6 and
FS Gateway 3.0.0  FS Gateway is installed as  InTouch is installed.
stand-alone product.
 FS Gateway is installed as a
 FS Gateway appears in hidden feature.

C HAPTER 6
Historian Server Requirements and
Recommendations
For the Historian to achieve maximum performance, make sure your hardware and soft ware meet the
following requirements. Because the Historian is a high-performance relational dat abas e, it is also
important to size your system to handle the level of data that you expect to store.
The Historian is tightly integrated with Microsoft products, and a working knowledge of both Microsoft
SQL Server and Microsoft Windows operating systems is required. For more information on Microsoft
SQL Server or Windows operating systems, see your Microsoft documentation.
In This Chapter
Server Requirements .................................................................................................................... 91
Requirements for Historian Management Tools .............................................................................. 93
Remote IDAS Requirements.......................................................................................................... 93
Disk Sizing and Data Storage ........................................................................................................ 94
Performance Considerations ....................................................................................................... 100
Networking Rec ommendations .................................................................................................... 102
Client Access ............................................................................................................................. 103
Support for Non-English Operating Systems................................................................................. 103
Integration with Other Wonderware Products ................................................................................ 104
System Sizing Examples ............................................................................................................. 104
Server Requirements
The minimum hardware and software requirements for the Historian are based on the tag count and the
anticipated data throughput rate. These requirements are divided int o four levels, which are outlined in
this section.
The recommended memory configuration for SQL Server (32 -bit) is to clamp memory consumption to 50
percent of the amount of physical memory installed on the server or 512 MB, whichever is larger. For
SQL Server Standard and Enterpris e editions (32 -bit), the recommended physical memory configuration
is 1 GB. The recommended Windows virtual memory setting is twice the amount of physical RAM
installed on the server. For installation requirements for SQL Server versions, see the Microsoft
documentation.
You need to ens ure that the memory that SQL Server res erves for the Historian is adequate for the
expected load. Based on your particular environment, you may need to adjust the SQL Server
MemToLeave allocation. For more information on MemToLeave, see the Microsoft documentation.
You can install the Historian on operating systems that have the User Account Control (UA C) turned on.
If you are running the Historian on a virtual server, the historian must ha ve an adequate CPU, adequate
network memory, and disk I/O resources at all times. Overloading the virtual server leads to
unpredictable behavior. See System Sizing Guidelines on page 10 for general hardware requirements.
Operating Systems
Any support ed operating system. See the AVEVA Global Customer Support (GCS ) Technology Matrix.

System Platform Installation Guide Historian Server Requirements and Recommendations
Microsoft SQL Server

For supported Microsoft SQL Server versions, see the AVEVA GCS Technology Matrix.
Disk Space
 300 MB of free disk space to install the Historian
 Appropriate space for history block storage. For more information, see Disk Sizing and Dat a Storage
on page 94.
Level 1 Server - Hardware
A Level 1 server can handle a load of about 5,000 tags. For example, 2,600 analogs, 2,200 discretes,
300 strings, and 20 non-I/O Server (manual) tags.
When replicating to Wonderware Online, each Level 1 server can support up to 15,000 tags and 5,000
values per second.
The requirements are:
 Processor:
o Minimum: P4 3.2 GHz CPU
o Recommended: dual -core CPU
 RAM:
o Minimum: 2 GB
o Recommended: 4 GB
 100 Mbps network interface card (NIC)
A Level 2 server can handle a load of about 100,000 tags, with 50% analog, 45% discrete, and 5% string
tags. The requirements are:
 Processor:
o Minimum: P4 3.0 GHz dual CPU
o Recommended: quad-core CP U
 RAM:
o Minimum: 4 GB
o Recommended: 8 GB
 1 Gbps network interface card (NIC)
A Level 3 server can handle a load of 150,000 tags, with 50% analog, 45% discrete, and 5% string tags.
The requirements are:
 Processor:
o Minimum: P4 2.7 GHz Xeon quad CP U
o Recommended: dual processor, quad -core CP Us
 RAM:
o Minimum: 6 GB
o Recommended: 12 GB

Historian Server Requirements and Recommendations System Platform Installation Guide
 1 Gbps network interface card

A Level 4 server can handle a load of 2, 000,000 tags, with 50% analog, 45% discrete, and 5% string
tags. The requirements are:
 Processor:
o Recommended: two quad-c ore CPUs
 RAM:
o Minimum: 24 GB
o Recommended: 48GB
 1 Gbps network interface card
A performance report for different historian systems is provided in S ystem Sizing E xamples on page 104.
High Availability Support

The Historian provides built-in support for Stratus ft3500 fault-tolerant servers. Other high availability
features include:
 Tiering - using the "replication" functionality with a small "local" Historian on site that replicates to two
"tier 2" Historians.
 Virtualization - using Hy perV or VMware high availability options with Historian running on a virtual
machine. For more information, see the System Platform in a Virtualized Environment
Implementation Guide.
 Redundancy - the Application Server can send data to two Historians at onc e and maintains
independent store-and-forward channels to each.
Requirements for Historian Management Tools

The management tools include the Historian System Management Console and the Historian Dat abase
Export/Import Utility. If you are installing the tools on a remote computer, the following requirements
apply:
 Any support ed operating system. See the AVEVA Global Customer Support (GCS ) Technology
Matrix.
 Microsoft Management Console 2. 0
 MDAC 2. 7
 Any support ed browser. See the AVEVA GCS Technology Matrix.
 20 MB of free disk space
Note: The Historian Data Importer is installed as part of the server installation.
Remote IDAS Requirements

A remote IDAS runs on all supported operating systems: domain member, stand-alone workstation, or
server.
To determine the CP U and memory needed for a remote IDAS, use the same guidelines of the Historian
computer. For more information, see Server Requirements on page 91.

The IDAS computer does not necessarily have to be as powerful as the server computer, because it will
not be performing all of the same functions (for example, processing SQL Server transactions), but it
should be powerful enough to handle the tag load that you expect.
The amount of free disk space required depends on whether or not you will have store-and-forward
enabled for the IDAS. If store-and-forward is enabled, you need to make sure that the disk space on the
remot e IDAS computer is sufficient to store cached data if the network connection to the historian fails.
Estimate the disk space requirements for a remote IDAS as that of the historian. For more information,
see Disk Space Requirements for Historical Data Files on page 96.
A remote IDAS configured for store-and-forward has more stringent requirements on memory to ens ure
that the IDAS local storage engine has sufficient res ources to run properly. In general, estimate memory
requirements for a remote IDAS configured for store-and-forward the same as you would for a historian
having the corresponding tag count.
Security Considerations for a Remote IDAS

If you set up a remote IDAS, you need to configure security settings that allow access permissions
between the remote IDAS and the Historian. For example, the historian needs to access the remot e
computer to start and stop the IDAS. Also, the remot e IDAS needs to access the historian computer to
send dat a. These are administrative tasks, which require administrative permissions.
When you install the historian, you must specify an administrative user account under which all of the
historian services run. Make sure that this same user account is added to the Administrators security
group on the remote IDAS computer. The existence of the same administrative user account on bot h the
computers, allows the historian to access the remote IDAS, and vice versa.
Note: A remote IDAS only requires the same administrative account to exist on the local comput er and
the historian. It is not required for you to log on to the remote IDAS computer using the administrator
account.
If you change the Windows login using the System Management Console, after installing the historian,
make sure that the user account change is reflected on the remote IDAS computer.
If you are running the historian in a domain environment (recommended), you can create the
administrative user account on the domain controller and add the account to the Administrators group on
the historian computer and the remote IDAS computer. Do not create a local user on any comput er with
the same name and/or password as the administrative us er account.
If you are running a remote IDAS in a workgroup environment, there is no centralized management and
authentication of user accounts (no domain controller). Create the same administrative user account on
each individual computer running a historian component. For example, if you have a computer running
the historian and plan to install remote IDASs on t wo other computers, creat e the user account (that is,
matching user nam es and passwords) on all three computers.
For information on work groups, domains, creating user accounts, and adding accounts to the
Administrators security group, see your Microsoft operating system documentation.
Disk Sizing and Data Storage

A number of storage-related questions must be answered when setting up the Historian. They include:
 How important is the data? Is it acceptable that four weeks of data is stored online and is then
over-written?
 How important is the configuration and event data? This type of information is stored in the Microsoft
SQL Server database.
 How often is data in the Microsoft SQL Server database changing?
 Is anyone in the organization going to require operating data that is older than a mont h? Older than a
year?

 How much is the SQL Server component of the historian expected to be used (for example, for the
event system)?
 How long can the system be off-line because of a component failure?
 What happens if the system stops storing dat a?
 What happens if stored data is lost because of a hard drive failure?
 Can the server equipment be taken off-line to perform repairs ?
Ask yourself questions like these to help you determine disk space requirements and how you should
plan to protect your data.
General Hardware Recommendations for Storage

The following are the general recommendations for the hardware used for storage:
 SCSI drives configured using hardware RAID is optimum. The disk space required is a function of
data rate and the desired history duration.
 NTFS is the only officially supported file system for a production environment.
Planning for Disk Space Requirements

There are a number of factors to consider when estimating the amount of disk s pace required to run the
Historian:
 Disk space required t o install the required software components and files needed t o run the historian.
 Disk space required to store the historian database files.
 Disk space required to store the historian data files.
 If a remote IDAS is used, the disk space required on the local IDAS computer to store cached data if
the network connection to the historian fails.
 We recommend that you keep sufficient free disk space (around 20%) so that you can run a disk
defragmenting utility without negatively affecting the historian performance.
Disk Requirements for Database Files

The Historian installation program adds the Runtime and Holding databases to the Microsoft S QL Server
by default. If you choose to store events to SQL Server, the A2ALMDB databas e is created.
Note: Historical plant data is not stored in the database files. This type of data is stored in special files
called history blocks.
 The Runtime database stores all historian configuration data and classic event data. The information
in the Runtime database is stored to disk as a databas e file named
RuntimeDat_116_<server_name>.mdf. Its associated log file is
RuntimeLog_116_<server_name>.ldf.
The configuration data in the dat abase file remains relatively static and usually never causes the file
size to go above 20 MB. However, if you set up classic events, records of event detections and the
results of any data summaries or snapshots increas e the size of the Runtime database file because
the tables are filling up. Also, entries are created in the log file for event -relat ed transactions. If the
database files are set to auto-size, the Runtime database file expands to accommodate
event-related dat a until the hard drive is full.

Note: In a 2, 000, 000 t ag system, 2.5 GB of space should be preallocated for data files when modification
tracking is not used. When modification tracking is used, 20 GB should be preallocated.
 The Holding dat abas e temporarily stores tag definitions being imported from InTouc h® HMI
software. The information in the Holding database is stored to a database file named
HoldingDat_116_<server_name>.mdf. Its associated log file is
HoldingLog_116_<server_name>.ldf.
 The A2ALMDB database stores alarm and event data. The information in the A2ALMDB databas e is
stored to a database file named A2LMDat _115_<server_name>.mdf. Its associated log file is
A2ALMDB _LOG.ldf.
The Runtime and Holding databases are set to automatically expand at a 10% rate (the default).
You cannot change these defaults during the installation. The dat abas es can be resized later using
Microsoft SQL Server utilities. For more information on sizing databases, see your Microsoft SQL Server
documentation for guidelines.
Note: If you are upgrading a previous version of the Historian, the installation program needs space to
save a copy of the old Runtime database while it creates the new one. To upgrade, the database space
required is twice the size of the old database, plus the database size for the new install.
Disk Space Requirements for Historical Data Files

The Historian stores historical plant data to hard disk in special files called history blocks. When you
install the historian, you are required to specify a storage location (directory) in which these files will be
dynamically created and subsequently filled. You must have at least 200 MB of free disk space for these
files to install the historian.
After the historian is up and running, when the free space on the drive containing the storage directory
drops below a minimum threshold, the oldest data is overwritten. It is very important that you allocate
enough disk space to store your plant data for the desired length of time.
The amount of data that can be stored to disk before running out of space is dependent upon the number
of tag values that are stored and how often they are stored. That is, the more tags you have, the fewer
values you can store per tag before you need to archive off the oldest data. Likewise, the higher the
specified storage rat e per tag, the faster the system runs out of space.
Important: You must have sufficient disk space in the circular storage area to hold at least two full
history blocks, plus the space specified for the minimum thres hold for the circular storage area. Use the
System Management Console to view or change the minimum threshold value.
Storage and Network Transmission Sizes for Tags

The following table lists the storage and network transmission sizes for various tag types.
Storage Engine - Network

Storage Engine - Storage Transmi ssi on Item Size
Tag Type Item Size (Bytes) (Byte s)
Analog - Integer 8 34
Analog - Floating Point 8 34
Analog - Double 12 38
Discrete 5 31


String 5+A vgStringLength (5+A vgStringLength)+26
Analog Summary 37 63
Discrete State Summary 40 66
Analog State Summary 28 * NumberOfStates (28*NumberOfStates)+26
String State Summary (28+A vgStringLength) * ((28+A vgSt ringLength) *

NumberOfStates NumberOfStates)+26
Alarm 325 6061
Acknowledgement 325 6066
E vent 300 5048
The storage size is used for estimating the space required for storage.
The network transmission size is used for calculating the net work bandwidt h required between HCA L
and the historian.
If you enable compression on the AppEngine from which events are originating, then the net work size is
reduced by approximately 80%.
For alarms and events, the network transmission size assumes that the average name length for each of
the alarm properties is 20 characters.
The following table provides some sizing examples.

String Tags (32 byte string) 5+32 = 37 (5+32)+26 = 63
State Summary for Analog (for 28*10 = 280 71*10 = 710

10 states)
State Summary for Discrete 20*2 = 40 68*2 = 136
(for 2 states)
State Summary for String (10 (1+32)*10 = 330 (69+32)*10 = 1010
states and 32 byte string)
Note: Current space calculations are different than the calculations used by the classic storage system.
Disk Space Estimation

This section provides guidance on how to determine the appropriate history block duration. A history
block duration can range from 1 hour to 24 hours, with a default of 24 hours.

For retrieval performance, it is better to have longer block durations. However, if the incoming data rate is
too high during a 24-hour period, the Original.dat file in which data collects may grow so large that issues
occur for history block management and ot her aspects of the storage subsystem.
We recommend that you tune the history block duration so that the size of the Original.dat file does not
exceed 8 GB per history block.
You can estimate how many bytes this data rate generates in one hour by using the following formula:
N kbps = (N / 8) bytes per second = (450 * N) bytes per hour
Where N is the transmission item size for the type of data that you are storing. For information on
calculating this number, see Storage and Net work Transmission Sizes for Tags on page 96.
If you multiply this by the history block duration, you can get an estimate of the biggest data file
containing streamed and forwarded data, Original.dat.
If that estimate is larger than 8 GB, keep reducing the history block duration until the estimate is under
the 8 GB limit.
Bandwidth Estimation for Streaming Data

The network bandwidth required can be estimated by adding the data transmission rate for all data types
and the network overhead. Network overhead is approximately 4% of the total transmission rate,
assuming the data rate is above 1000 points/sec. The estimated bandwidth would be the minimum
bandwidth required for replication with reliable network (always connected). However, if there are
network disconnections/reconnections, using only the minimum required bandwidth would make the
"catch-up" process take a long time if possible. It is recommended that you add a 30% safe margin to the
estimated bandwidth to ensure that the forwarding process can complete quickly if an unexpected
network outage occurs.
The formula for estimated bandwidt h is as follows:
BandwidthStreaming = 1.04 * 8 * Each Tag Type (Data Rat e * Transmission Item Size)
BandwidthRecommendedStreaming = 1.3 * BandwidthStreaming
For example, with the following replication configuration:
1. Simple Replication - 798 4-byte analog tags changing every second.
2. Simple Replication - 815 discrete tags changing every second.
3. Simple Replication - 187 string tags (20 bytes string) every second.
4. 1 Minute Analog Summary - 800 tags
5. 1 Hour Analog Summary - 800 tags
6. 1 Minute State Summary (Analog, 10 states) - 800 tags
7. 1 Hour State Summary (Analog, 10 states) - 800 tags
The average number of bytes transmitted every second for each of the above replication types is as
follows. For a table of transmission sizes, see Storage and Net work Transmission Sizes for Tags on
page 96.
1. 798 * 34 = 27132 Bytes
2. 815 * 31 = 25265 Bytes
3. 187 * 52 = 9724 Bytes
4. 800 * 96 / 60 = 1280 Bytes
5. 800 * 96 / 3600 = 21 Bytes
6. 800 * 710 / 60 = 9467 Bytes

7. 800 * 710 / 3600 = 157.8 Bytes

BandwidthStreaming = 1.04 * 8 * (27132 + 25265 + 9724 + 1280 + 21 + 9467 + 158) = 608 K bps
BandwidthRecommendedStreaming = 1.3 * 608 Kbps = 790 Kbps
Bandwidth Estimation for Store-and-Forward Data

If there is a network disconnection, HCA L sends data to local storage and later forwards the data to the
historian. Aft er the forwarding process starts, HCAL will try to send as much as data as possible with a
large packet. The forwarding bandwidth is the bandwidth required to stream the store-and-forward data.
The store-and-forward storage size is the s ame as for loc al historian storage. The following table lists the
average sizes used for bandwidth estimation used in this example.
Storage Item Size

Tag Type (Byte s)
Discrete Tags 5
Analog Tags (4 byte data) 8
String Tags (32 byte string) 37
Analog Summary (4 byte analog) 37
State Summary for Analog (for 10 states) 28 * 10 = 280
State Summary for Discrete (for 2 states) 20 * 2 = 40
State Summary for String (10 states and 32 byte string) (1 + 32) * 10 = 330
The forwarding bandwidths are calculat ed using the following formulas:

BandwidthForwarding = 1.04 * 8 * Each Tag Type (Data Rate * Storage Item Size)
BandwidthRecommendedForwarding = 1.3 * BandwidthForwarding
For this example, if all are stored in the local storage engine and forwarded later, the number of bytes
required for every second is as follows:
1. 798 * 8 = 6384 Bytes
2. 815 * 5 = 4075 Bytes
3. 187 * 25 = 4675 Bytes
4. 800 * 37 / 60 = 493 Bytes
5. 800 * 37 / 3600 = 8 Bytes
6. 800 * 280 / 60 = 3733 Bytes
7. 800 * 280 / 3600 = 62 Bytes
BandwidthForwarding = 1.04 * 8 * (6384 + 4075 + 4675 + 493 + 8 + 3733 + 62) = 162 Kbps
BandwidthRecommendedForwarding = 1.3 * 162 Kbps = 211 Kbps

Time Estimation for Store-and-Forward Data

The actual time taken to forward store-and-forward snapshots depends on the amount of data
accumulated and the bandwidth limit. HCA L typically waits for about 30 second to attempt forwarding
process after reconnection. It may need to wait for a longer time if the historian is busy.
To simplify the calculation, the following is assumed:
 HCA L can start forwarding immediately without interruption
 The bandwidt h is 30% above the data rate before disconnection
The time taken to forward is as follows:
TimeForwarding = TimeInStoreforward * RatioForwardingDataSize / 0.3
Where RatioForwardingDataSize = Forwarding data Size / Streaming dat a size
For example, the date rate is 1 Mbps and the bandwidth is 1.3 Mbps. Assume you have simple replication
for analog tags and store-and-forward data has been accumulating for 1 hour.
RatioForwardingDataSize = 8 / 34 = 0.235
TimeForwarding = 60 (minutes) * 0. 235 / 0.3 = 47 minutes
About Data Compression and the Buffer Age Limit

Bandwidth usage is reduced by about 80% if compression is enabled. This assumes that the data rate is
high enough to keep the buffer (64K) filled to have better compression ratio. For analog tags, the data
rate is roughly 2000 values/second.
When the data rate is low, enabling compression may not be effective. To fill the buffer with low data rate,
you can select the Wait to send incomplete packets option (B ufferAgeLimit attribute) for the
AppEngine configuration. This attribute is not applicable to replication.
Performance Considerations
For a complete Historian system, the following components put a demand on memory.
 Internal historian subsystems, such as the Configuration Manager, data acquisition, and data
storage
 The associated Microsoft SQL Server
 The operating system
 Client access (data retrieval), whic h includes caching
When det ermining the amount of memory to purchase, remember that adding more memory is the
cheapest and easiest thing that you can do to improve performance. Increasing the amount of memory
reduces the amount the server has to use virtual memory, thus lowering the load on the storage
subsystem. Even if you have a large amount of memory, additional memory is used as additional disk
cache, speeding up disk access and therefore file service. Also, processes needed by the server
become faster because they are memory-resident.
A major factor in system performance is the amount of plant dat a you anticipat e storing in the system,
including considerations about how oft en that data is stored and retrieved. In general, the more you
store, the more often you store it, and the more you retrieve it, the slower the system. The major storage
factors affecting the performance of the system are:
 Effective anal og flow rate (analog updates per second).
 Period of online data storage required.
 Effective discret e variable flow rate.

 Number of conc urrent end users required.

 Complexity of end user queries.
 Number and size of string tags, as well as the effective flow rate of string values.
 Number and duration of string tag retrieval queries, as well as the frequency at which these queries
are exec uted.
Server Loading
When a user connects to the Historian wit h a client, configuration information is immediately requested
from the historian. This information includes the tags that the server stores, their descriptions,
engineering units, and ot her tag data. SQL Server reads this information from the database (stored on
disk) and places it in memory.
As the user selects time periods to trend, the historian reads data from files located on the disk and
prepares the res ults of the client's data request to be transmitted back to the client. The ability of the
server to quickly handle subsequent requests for data from the same client and others is dependent on
the server's ability to keep as much information in memory without having to again access data from the
disk.
As a higher load is placed for memory, a higher load is placed on the disk I/O system as the s erver has to
use disk caching and read from the data files.
The following table summarizes the loading for various systems.
System Load Description
Acquisition and Base load of the historian. This load exists as long as the system is running.
storage However, this load is not affected by client activity.
Retrieval Variable loading caused by data ret rieval from client applications. When the
client initially connects, the data requested is configuration data, which is
stored in SQL Server. The historian requests data from SQL Server, causing
its loading to increase. As the client requests historical data, the disk time
increases as information from the data files is transferred to memory. This
continues as the client requests additional data. If the client application
requests data that has already been transferred to memory, there is no
associated disk activity and trans fer of data to memory.
The server must be able to adequately handle the variation on loading caused by the client applications.
To accomplish this, make sure that your hardware is sized so that it can handle the base load creat ed by
the acquisition and storage systems and that there are adequate resources still available for the retrieval
system.
IDAS Performance
An IDAS can ac quire an unlimited number of real -time data values, from an unlimited number of I/O
Servers, each with an unlimited number of topics. However, IDASs are subject to the following
limitations.
 The maximum sustained data throughput for any single IDAS is 30,000 items per second for
real-time dat a. For late or old data, the maximum throughput is 9,000 items per second. The total
combined throughput (real-time data plus late or old data) cannot exceed 30,000 items per second.
For higher-volume applications, you can set up multiple IDASs to serve a single storage subsystem.

 The size of any data value is limited to 64,000 bytes.

 The maximum number of tags supported by any single IDAS is 30,000.
Tiered Historians
If you are installing a tiered historian, tier-1 nodes use the same basic configuration for the number and
types of tags and data collection rates.
The tier 1 configuration should be "delta" data collected and stored:
 12,000 analog tags every 2 seconds
 2,900 discrete tags every 2 seconds
 100 32-character string tags every 30 seconds
For the analog and discrete tags, the averages and value state aggregates are:
 6000 tags with an hourly calculation performed at the top of each hour
 6000 tags with 1-minute calculations performed at the top of each minute
plus
 1500 tags replicated (not aggregat ed) in tier 2
 1500 tags stored only in tier 1 (no aggregates or replication)
Storage Subsystem Performance

The storage subsystem can support a continuous data acquisition rat e of 150,000 updates per second.
The storage sub-system also supports a burst rate of 300,000 updat es per second up to 1 second.
The classic storage subsystem can support a continuous real -time data acquisition rate of 30,000
updates per second and a burst rate of 60,000 updates per second up to 1 second.
The storage subsystem processes all real -time data as a high-priority task that is never int errupted.
However, data received from "manual" methods (such as UPDA TE/ INSE RT commands, CSV file
imports, or store-and-forward) is handled by a low priority task. If the system is generally busy, then it
may take some time for the manual data to be posted.
Networking Recommendations
The Historian is a highly configurable package that can be set up in many different ways depending on
your needs.
The Historian can use any prot ocol currently supported by Microsoft SQL Server 2012. You can use the
default Microsoft SQL Server 2012 protoc ol (named pipes) with TCP/IP. TCP/IP is required if S uiteLink™
is used.
Do not use the historian computer as a domain controller.
It is highly recommended that you run the historian on a dedic ated computer. For example, running the
historian on a mail server or an Internet server may impact performance.
Generally, it is recommended that you split the process and IS networks to ensure that the process
network does not become overloaded. The following illustration shows one possible network architecture
where the historian is the link between the process net work and the business LAN/WAN

For this architecture, install two network cards on a server computer and configure them to segment the
IS network from the process network.
Note: All tags to be stored in historian are on "advise" all the time. This may cause heavy load conditions
on the process network. Before you install the historian, investigate the possible load impact of installing
the historian on your net work.
Client Access
All clients should connect to the Historian using the default Microsoft SQL Server connection. Usually,
this means using the name of the computer on which the historian is running as the server name when
logging on.
To change the default network prot ocol used by Microsoft SQL Server to somet hing ot her than named
pipes, configure the client network access using the SQL Server Client Network Utility. For more
information, see your Microsoft SQL Server documentation.
Support for Non-English Operating Systems

The English version of the Historian, the Historian Dat abas e Export/Import Utility, and the Historian Data
Importer run on localized versions of all the supporting operating systems for the following languages.
Set the regional settings before you install SQL Server. The corresponding version of Microsoft SQL
Server for the required language must be used.

 German
 Frenc h
 Japanese
 Simplified Chinese
The following entities are not supported in double-byte languages:
 Domain names, user names, and passwords (including SQL Server login names and passwords).
 Names of I/ O Server host machines, I/O Server application names, topic names, and item names.
 Any text associated with licensing.
Integration with Other Wonderware Products

The Historian is Wonderware's open relational database for plant and process data. Many of the features
of the historian allow it to be used with many of Wonderware's other products.
The historian can store data from any application that supports SuiteLink™. Examples of Wonderware
®
applications that can send data to the historian are Application Server, I/O Servers, and InTouc h
WindowViewer™.
Any client application that can retrieve information using SQL can retrieve data from Historian. For
example, some Wonderware products that can retrieve data by means of SQL queries are the InTouch
HMI, Historian Client applications and controls, Manufacturing Execution Module, and InBatch™
products. The historian further extends SQL to improve the ability to handle time series data.
Also, the Historian I/O Server (aahIOS vrS vc.exe) is an interface for clients to access curre nt data values
a historian by means of the SuiteLink protocol. The Historian I/O Server can update items with current
values for given topics, providing "real -time" I/O Server functionality.
Finally, you can use InTouch to configure the historian by import ing tag definitions and I/O Server
definitions from the InTouch Tagname.x file into the Runtime database.
System Sizing Examples

To help you determine how to size your system, performance reports are provided for different Historian
configurations.
Important: The information presented here is a guideline only. The actual results in your environment
may vary.
Process Historian Sizing Examples

Performance reports are provided for various levels of a Historian.
Server 1 (Non-Tiered): 2.4 GHz Single Processor Quad-Core CPU

Historian Specifications
 DELL OptiPlex 755 with 2.4 GHz single processor quad-core CP U
 4 GB RAM
 512 MB Virtual Memory
 1 Gbps NIC
 Microsoft SQL Server 2008 SP3 Standard Edition
 SQL memory clamped @ 512 MB

 12-hour history block duration
Tag Information
Tag count (total) = 5,187
Analog tags = 2,607
Discrete tags = 2,285
String tags = 295
Manual tags = 17
Update rate of +/- 5,000 updates/second
Remote IDAS
None.
Event Information
 3 snapshot events, each having:
o 1 analog snapshot
o 1 discrete snaps hot
o 1 string snapshot
 2 summary events, each having:
o 1 AVG calculation (1 tag every 8 hours)
o 1 MA X calculation (1 tag every 8 hours )
o 1 MIN calculation (1 tag every 8 hours)
o 1 SUM calculation (1 tag every 8 hours)
 1 SQL insert every 4 hours
 2 SQL multi-point updat es every hour
Query Load
For the following seven queries, each are occurring at different times in the hour:
 1 query (trend):
o live mode - 1 second updat e
o 1-hour duration
o 10 tags (7 analogs, 3 discretes)
 1 query: 1-hour range / hour (1 tag)
 4 queries: 15-minut e range / hour (1 tag)
 1 query: 24-hour report every 24 hours (25 to 30 tags)
Performance Results
Category Value
A verage CP U load (%) 1.896

Category Value
Historian memory (Private Bytes) consumption (MB ) 714
Number of online history blocks 18
Uncompressed hard drive disk space per history block (MB) 1002
Server 2 (Non-Tiered): Four Dual-Core 2.7 GHz CPUs

 DELL Precision WorkStation T5400 with four dual-core Intel Xeon 2.7 GHz CP Us
 4 GB RAM
 1 Gbps NIC
Tag Information
Analog tags = 39,359
String tags = 295
Manual tags = 5,057
Remote IDAS
One remote IDAS:
 P4 1.7 GHz
 1 GB RAM
 34,000 tags via the rem ote IDAS and the rest via the local IDAS
Note: Because this configuration was used for performance and stress testing, the remote IDAS tag
count is more than the recommended 30,000 maximum.
Event Information
o 1 analog snapshot
o 1 string snapshot


 2 SQL multi-point updat es every hour
Query Load
o 1- hour duration
Performance Results
Category Value
Uncompressed hard drive disk space per history block (GB) 4.12
Server 3 (Non-Tiered): Four Dual-Core 3.4 GHz CPUs

 DELL PowerEdge 6800 with four dual-core Intel Xeon 3.4 GHz CPUs
 16 GB RAM
 1 Gbps NIC

Tag Information
Analog tags = 73,600
String tags = 6920
MDAS
In the total tag count, 4009 tags originated from Application Server.
Remote IDAS
Two remote IDASs:
 Remote IDAS 1: P4 1.9 GHz, 1 GB RAM
 Remote IDAS 2: P4 2.5 GHz, 512 MB RAM
44,370 tags via the remote IDAS 1
45,584 tags via the remote IDAS 2
44,383 tags via the local IDAS
Note: Because this configuration was used for performance and stress testing, the remote IDAS tag
counts are more than the recommended 30,000 maximum.
Event Information
o 1 analog snapshot
o 1 string snapshot
 2 SQL multi-point updat es:
o 1 every 15 minutes
o 1 every 30 minutes
Query Load
o 15-minute duration


Performance Results
Category Value
A verage CP U load (%) 10
Uncompressed hard drive disk space per history block 1.81

(average GB)
Server 4 (Tier-2): Eight Dual-Core 2.67 GHz CPUs (Hyper Threaded)

 DELL PowerEdge T610 wit h Eight Dual-Core 2.67 GHz CPUs (Hyper Threaded)
 48 GB RAM
 48 GB Virtual Memory
 1 Gbps NIC
 Windows Server 2012 Data Center Edition
 Microsoft SQL Server 2012 SP1 Standard and Enterprise
Tag Information
Tag count (total) = 2,000,000
Analog tags = 1,000,000
String tags = 100,000
Update rate of +/- 150,000 updat es/second
Query Load
The following query is occurring at different times in the hour:
o 15-minute duration
o 500 tags (250 analogs, 225 discretes, 25 strings)

Performance Results
Category Value
Historian memory (Private Bytes) consumption (MB ) 11,124
Uncompressed hard drive disk space per history block 10.00

(average GB)
SCADA (Tiered) Historian Sizing Examples

Performance reports are provided for various levels of a multiple Historian SCA DA configuration.
Topology 1: Centralized Tiered Historian Topology on a Slow/Intermittent

Network
This topology consists of ten tier-1 historians performing simple and summary replication of the same
tags independently to two tier-2 historians. This topology is target ed to reflect the requirements of
geographically distributed S CADA applications operating on slow and int ermittent networks.
The 400 Kbps data transfer limit reflects a typical data transfer speed between remote locations over the
Internet. The data transfer from each tier-1 historian to a tier-2 historian is assumed to be through a
dedicated 400 Kbps connection; multiple tier-1 historians do not share the same 400 Kbps connection. It
is assumed that the 400 Kbps is a bandwidth that can be fully used.
Tier 2 Historian Specifications

 16 GB RAM with enabled PAE or 4 GB RAM
 Disk I/O subsystem of a 100MB/s throughput, 6 ms access time.

 100/1000 Base-T network card

 400 Kbps network connection (actual usable bandwidth)

 DELL Precision WorkStation T5400 with dual processor quad-core Intel Xeon 2.7 GHz CP Us
 4 GB RAM
Loading Information
Assume that the total tag count on the tier-1 historian is 15,000.
The tier-1 historian receives 15,000 tags from I/O Servers of the following types and data rates:
 12,000 4-byte analog delta tags changing every 2 seconds: (10,000 always fitting the real -time
window and 2,000 falling outside of the real-time window being 50 minutes late).
 2,800 1-byte discret e delta tags changing every 2 seconds
 200 variable-length string delta tags of 32-character length changing every 30-seconds
The tier-2 historian stores the following:
 6,000 tags with hourly analog summary calculations performed at the top of each hour (using 6,000
4-byte analog tags as tier-1 tags)
 Another 6,000 tags with 1-minute analog summary calculations performed at the top of each minute
(using 6, 000 4-byte analog tags as tier-1 tags)
 1,500 tags replicated (as simple replication) to tier -2 (using 1, 400 1-byte discret e tags and 100
variable-lengt h string delta tags as tier-1 tags)
 Another 1,500 tags only stored on tier-1 (using 1, 400 1-byte discrete tags and 100 variable-length
string delta tags as tier-1 tags)
Performance Results for the Tier-2 Historian

Category Value
A verage CP U load (%) (with no queries executing) 1%
Historian memory (Virtual Bytes) consumption (GB) 3.05 GB

Uncompressed hard drive disk space per history block 888 MB

(average MB)
Latency Results
Category Value
Fastload (1 day fastload) 10.33 hours
Simple replication 4 seconds

Category Value
Summary replication 4.6 seconds
Latency is the difference in time between when the value is received by the tier-1 historian and when it is
received by the tier-2 historian.
Topology 2: Centralized Tiered Historian Topology for a Single Physical Location

A 100 Mbps data transfer limit reflects a typical data transfer speed within one location, but distributed
over several buildings. In this case the 100 Mbps bandwidth is a physical characteristic of the
connection. It is assumed that up to 33% of that phys ical bandwidth can be used.
Tier-2 Historian Tier-2 Historian
100-Base T
Tier-1 Historians
(standard configurations)

 16 GB RAM with enabled PAE or 4 GB RAM
 100 Kbps network connection (actual usable bandwidth)

 4 GB RAM
 100/1000Base-T net work card
Loading Information
Assume that the total tag count on the tier-1 historian is 15,000.
The tier-1 historian receives 15,000 tags from I/O Servers of the following types and data rates:

 12,000 4-byte analog delta tags changing every 2 seconds: (10,000 always fitting the real -time
window and 2,000 falling outside of the real-time window being 50 minutes late).
 2,800 1-byte discret e delta tags changing every 2 seconds
 200 variable-length string delta tags of 32-character length changing every 30-seconds
The tier-2 historian stores the following:
 6,000 tags with hourly analog summary calculations performed at the top of each hour (using 6,000
4-byte analog tags as tier-1 tags)
 Another 6,000 tags with 1-minute analog summary calculations performed at the top of each minute
(using 6, 000 4-byte analog tags as tier-1 tags)
 1,500 tags replicated (as simple replication) to tier -2 (using 1, 400 1-byte discret e tags and 100
variable-lengt h string delta tags as tier-1 tags)
 Another 1,500 tags only stored on tier-1 (using 1, 400 1-byte discrete tags and 100 variable-length
string delta tags as tier-1 tags)

Category Value
A verage CP U load (%) (with no queries executing) 1.55%

(average MB)
Latency Results
Category Value
Fastload (1 day fastload) 9.92 hours
Simple replication 1.65 seconds
Summary replication 1.51 seconds

Topology 3: Simple Tiered Historian Topology for a Modem Configuration

In a modem configuration, the network bandwidth between the tier-1 and the tier-2 historians is limited by
56 Kbps. Because the tag count and the replication data rate of the tier -1 historian should be very limited,
it would be sufficient to consider only one tier -1 historian performing simple replication to one tier-2
historian over a modem network.

 4 GB RAM
 56K modem

 OptiPlex 755 with single processor quad-c ore CPU 2. 4 GHz
 4 GB RAM
 56K modem
Loading Information
In the tier-1 historian modem configuration, the tier-1 historian receives 3,000 tags from I/O Servers of
the following types with average updat e rate 300 items per second:

 1,500 4-byte analog delt a tags (1,400 always fitting the real -time window and 100 falling outside of
the real-time window being 50 minutes late)
 1,350 1-byte discret e delta tags
 150 variable-length string delta tags of 32 bytes each

Category Value
A verage CP U load (%) (with no queries executing) 1%

(average GB)
Latency Results
Category Value
Fastload (1 day fastload) n/a
Simple replication 5 seconds
Summary replication n/a

C HAPTER 7
Historian Server Installation and
Configuration
In This Chapter
Preparing for the Historian Installation .......................................................................................... 117
Microsoft SQL Server Installation ................................................................................................. 117
Historian Installation Features...................................................................................................... 118
About Historian Installation .......................................................................................................... 119
Testing the Installation ................................................................................................................ 120
Antivirus Software....................................................................................................................... 120
Historian Menu Shortcuts ............................................................................................................ 120
Repairing the Historian................................................................................................................ 120
Modifying the Historian Installation ............................................................................................... 121
Uninstalling the Historian............................................................................................................. 124
Upgrading from a Previous Version.............................................................................................. 125
Preparing for the Historian Installation

A complete Historian system consists of the following software components:
 Microsoft SQL Server
 Historian program files, database files, and history dat a files
 System Management Console, the configuration and control tool
 One or more local or remote IDASs (at least one must be defined)
 Historian documentation.
You should have a definite plan for implementing the historian in your plant environment before you start
the installation process. This plan should include the type of network architecture for the historian
system, the amount of disk space required for dat a storage, and the amount of space required for the
historian database files and log files.
Also, any administrative security accounts that you specify for eit her the Microsoft SQL Server or the
historian should be accounts that do not change often, if ever. In particular, do not change an
administrative password during any part of the installation process.
You must have administrative rights on the local comput er to install the historian. The account with which
you log on to the computer must also be a sysadmin for the SQL Server or you must be able to provide a
sysadmin account for the SQL Server when prompted for it during the installation.
The installation program detects any previous versions of the historian and notifies you of your migration
options.
Microsoft SQL Server Installation

You need to install and run the required version of Micros oft SQL Server before installing the Historian.

System Platform Installation Guide Historian Server Installation and Configuration
Configure the following Microsoft SQL Server options before installing the historian. If you already have
Microsoft SQL Server installed, you can run the Microsoft SQL Server setup program to change these
options. Microsoft SQL Server options should only be configured by a qualified Windows or SQL Server
administrator. For more information, see your Microsoft SQL Server documentation.
 Microsoft Client Utilities must be installed.
 The historian must run with the Microsoft SQL Server default instance name (that is, the computer
name).
 During the Database Engine Configuration step of the SQL Server installation, make sure t o add the
ArchestrA User Account and/or the local Administrators group as aut horized users.
 Remote Microsoft SQL Servers are not supported by the historian.
 For net working support, use named pipes and any other support required at your site. However, you
must select at least named pipes and TCP/IP sockets (the defaults). It is highly recommended that
you do not modify the default configuration for named pipes and TCP/ IP sockets.
 As you select the path to the data files, you must consider that the historian Runtime database will
grow, especially if you are going to use the event subsystem (including summaries ) or storing data in
the ManualAnalog, ManualDiscrete, or ManualString tables.
 The Microsoft SQL Server services should be installed using the local system account. The account
you specify should be an account that does not change oft en, if ever.
 For obvious security reasons, you should not use a blank password for Microsoft SQL Server.
 Both case-sensitive and case-insensitive SQL Servers are supported. However, you should avoid
mixing case-sensitive collations in tiered historian topologies.
 The SQL Server e-mail functionality requires a Windows domain user account. You can change the
service account after SQL S erver is installed. However, it is highly recommended that you use an
account for which the password does not change often. For more information on SQL Server e-mail,
see your Micros oft SQL Server documentation.
Historian Installation Features

The Historian installation program allows you to install some of the features of the system separately.
The following table describes the various historian features that can be installed. The online help is
installed with all the features.
For information on hardware and software requirements for installing any of these features, see the
Historian Readme file..
Feature Description
Historian This option installs or re-installs the historian, configuration tools and
selected subcomponents.
IDAS An IDAS, which can be used remotely. The IDAS is always installed if you
select to install a complete historian.
Configuration Tools The server management tools include Historian Configuration Editor and
Historian Management Console. Both of these applications are MMC
snap-ins that are contained in the System Management Console. These
tools are always installed on the same computer as the historian and can
also be installed on a different computer on the network. The Historian
Database Export/Import Utility is also an installed configuration tool.

Historian Server Installation and Configuration System Platform Installation Guide
Feature Description
ActiveE vent ActiveE vent is an ActiveX cont rol that allows you to notify the historian
classic event system when an event has occurred in another application,
such as InTouch HMI software.
InSight Client Historian InSight is a browser client included with the Historian. It is the
on-premises version of Online InSight, and provides instant access to
production and performance dat a.
Historian This option installs historian extensions for OData and SQL Server
Extensions Reporting Services (SSRS ).
About Historian Installation

Historian installation is performed in two phases. In the first phase, the installation program performs the
following operations:
 Deploys the common components, such as SuiteLink and the Licens e Viewer, unless they are
already installed and validated.
 Locates the required version of a running Microsoft SQL Server on the local comput er.
 Logs on to the installed Microsoft SQL Server using the account of the person who is currently
logged on. This account must be an administrative account on the local comput er.
 Checks for required disk space based on the features that you select.
 Creates the historian directories on the hard disk, installs program files for the selected features, and
registers components. For more information, see Historian Installation Features on page 118.
 Populates the historian program or startup group with icons.
The Database Configuration Utility automatically runs after the historian program file installation is
complete. This utility:
 Creates and/or configures the required databases.
 Creates the directory for the history data files (history blocks).
To install the Historian for use in a tiered historian environment, install the Historian on the individual
computers, then implement them as described in the "Managing and Configuring Replication" chapter of
the Historian Administration Guide.
Use the System Platform installation program to install the entire system or any of the features. It is
assumed that you are familiar with the installation options. The installation program does not log any
errors that may occur.
You must have administrati ve rights on the local comput er to install the historian. The account with which
you log on to the computer must also be a sysadmin for the SQL Server or you must be able to provide a
sysadmin account for the SQL Server when prompted for it during the inst allation.
Important: Do not install the Historian on a computer named INSQL, because this conflicts with the
name of the Historian OLE DB provider and the installation eventually fails.
For detailed instructions on installing, see System Platform Installation on page 7.

After the installation completes, configure the server using the instructions in Configuring Databases and
Data File Locations on page 43.
Refer to the System Platform Readme before using the historian.

Testing the Installation

Test the Historian installation to make sure that everything is installed correctly and is working properly.
To test the installation
1. Start the Historian.
2. Start the storage system and check that the system is receiving data from the system tags.
After the historian is installed, no additional configuration is required to run client tools against the server
using named pipes. However, you may want to change the system or server configuration using the
System Management Console.
Antivirus Software
After installing the Historian, configure your antivirus soft ware. Be sure to exclude any folder that
contains history blocks. Refer to TechNote TN2865, available from the AVEVA Global Customer Support
(GCS ) web site, for important information about antivirus software. Enter your GCS credentials to access
the Tech Note.
https://softwares upportsp.schneider-electric.com/#/okmimarticle/docid/tn2865
Historian Menu Shortcuts

The following Start menu shortcuts are created in the Wonderware Historian folder.
 Administration
 Configuration Export and Import
 Data Import
 InSight
 Query
 Trend
The following Start menu shortcuts are created in the Wonderware Utilities folder:
 Change Net work Account
 Configurator
 SQL Access Configurator
 System Platform Management Console
Note: If you performed a complete historian installation, the System Management Console is configured
so that the local SQL Server is already registered. However, if you only installed the client tools, the
console is empty.
Repairing the Historian

For a repair, the installation program automatically detects if you have an existing copy of the Historian
on your computer and then reinstalls missing or corrupt program files, registry keys, and shortcuts.
For detailed repair instructions, see Repairing an Installation on page 56.
To repair a database, use the Databas e Configurator. For more information, see Configuring Databases
and Data File Locations on page 43.

Modifying the Historian Installation

You can modify the Historian features that are already installed.
For detailed modification instructions, see Modifying an Installation on page 55.
To modify the disk directories for the database files and/ or the history data files (history blocks), use the
Database Configurator. For more information, see Configuring Databases and Dat a File Locations on
page 43.
Using HTTPS Instead of HTTP for Historian Client, InSight, and REST
APIs
Typically, customers using the Open Data (ODat a) protocol can connect to a Wonderware Historian
server from Wonderware Historian Client or other client application using an unenc rypted (HTTP )
connection. (E ven without an encry pted connection, the user cred entials exchanged during login are still
encrypted.) It is possible to use an encrypt ed connection (HTTPS) for OData, but in that case, you must
first install and configure a TLS (transport layer security) certificate.
The following sections describe how to install and configure a TLS certificate.
About TLS Certificates

If you use an HTTPS connection with Wonderware Historian, you will need a TLS certificate. The
certificate can be from a trusted aut hority or a self-signed certificate.
TLS allows for encrypted authentication credentials to be passed bet ween a server and client. A TLS
certificate containing a private key is passed between the client and server to verify identification and
allow access.
Creating Self-Signed Certificates

If you choose to use a self-signed certificat e with Wonderware Historian, you are responsible for
configuring all clients to trust that certificate. Consult you operating system and/or browser
documentation for details about how to trust a self-signed certificate.
To create a self-signed certificate
 In Windows PowerS hell, run this command:
New-SelfSignedCertificate -DnsName <hostname> -CertStoreLocation

"cert:\LocalMachine\My"
Where
o <hostname> is the name or IP address of the computer running InSight.
Note: Remote users of InSight must use the name or IP address used in the certificate while
browsing to avoid receiving TLS warnings.
Acquiring a Certificate Thumbprint

To acquire a thumbprint (certha sh) for your certificate

1. In Micros oft Management Console (MMC), double -click the certificate to open it.
2. Click Thumbprint.
3. Copy the thumbprint (certhash) and paste it into Notepad or other editor. Remove spaces bet ween
the hexadecimal digits.
4. Save the file in ANSI format.
5. Copy the resulting thumbprint (certhas h) for use when you bind certificates to the port.
Binding Certificates to Secure Socket Layer Ports

Once you have a certificate t o be used for HTTPS communic ation, you need to bind it to the port used for
that communication. The port acts as a self-hosted endpoint for communication with the server.

To bind a certificate to an SSL port for self-hosting

 At the command prompt, run this command as administrator (all on one line):
netsh http add sslcert ipport=0.0.0.0:<port>
appid={12345678-db90-4b66-8b01-88f7af2e36bf} certhash=<certificate_hash>
For every endpoint mapping, you need to supply three values:
o ipport -- identifies the ip and port
Specified as ipport=0.0.0.0:<port>, where the zeros mean all IP addresses on that port. If you
are using HTTPS and a gateway, this is port 32569. So, in that case, you would use "
0.0.0.0:32569", which means all IP addresses on port 32569.
o certhash -- the certificate's thumbprint
The certhash comes from the specific certificate you're using. Certhash is the identifier that
maps the certificate to the specified IP endpoint. This identifier is contained in the TLS certificate
(also called a SSL certificate).
Type your certificate’s identifier in this location.
o AppID -- fixed for HttpListener Hosting
This value is static, so always use appid={12345678 -db90-4b66-8b01-88f7af2e36bf}
Next, view the binding to confirm the steps above worked.
To view the binding
1. Select the Windows Start button.
2. In the command box, type the netsh command using this syntax (all on one line):
netsh http show sslcert ipport=0.0.0.0:<port>
where "<port>" is the port you configured above.

You will see a display like this one:
Updating the Registry for OWINHost to Start in the Secured Mode

Once the binding is completed, you can modify the Windows Registry to start OWINHost in the secured
mode.
To update the Registry
1. Open Regedit.
2. In the left pane, navigate to this location for a 64-bit operating system:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ArchestrA\Historian\Setup\OWINHos
tCmdArgs
Or, for a 32-bit operating system:
HKEY_LOCAL_MACHINE\SOFTWARE\ArchestrA\Historian\Setup\OWINHostCmdArgs
3. Update the value as follows:
Value = -port <portNo> -secured 1
Now, you can specify an encrypted connection to the server.
Uninstalling the Historian

The uninstall program allows you to remove all the historian program files. The Runtime, Holding, and
A2ALMDB databases and the history blocks are not delet ed.
During t he uninstall, you have the option t o delete the configuration files (idatac fg_*.dat) creat ed by IDAS
and the Configuration Service.
For detailed uninstall instructions, see Uninstalling System Platform on page 57.

Upgrading from a Previous Version

You can upgrade directly to the Historian 2017 Update 3 SP1 from Wonderware Historian 2014 R2
(version 11.6.12100) SP1 and later versions.
You should upgrade the Historian Server before upgrading Historian remote IDAS nodes. Remote IDAS
nodes that are not upgraded to 2017 Updat e 3 SP1 will remain fully functional. However, it is strongly
recommended that you upgrade them to 2017 Update 3 SP1 to incorporate minor improvements and
simplify further upgrades and maintenance.
If you have been using replication, when upgrading Historian nodes, upgrade the tier -2 Historian node
first and then the tier-1 Historian node. A tier-2 node must use the same release of the Historian, or one
release newer than its tier-1 nodes. A tier-1 node cannot replicate to a tier-2 node running an earlier
version of the Historian.
About Database Migration

The data in an existing Runtime database can be migrated to a new Runtime database. The old Runtime
database is not delet ed. Keep the old database until the Historian migration is validated.
Important: Back up the Runtime database before performing the migration.
There is no migration for the content of the Holding database, because this database is used only to
temporarily hold dat a when importing an InTouch data dictionary.
Any configuration data associated with obsolete system tags is not migrated.
For the event subsystem, all SQL-based detectors and actions are migrated to the OLE DB syntax. If you
have any custom SQL-based detectors or actions, you need to rewrite them using the OLE DB syntax.
History data that is stored in SQL Server tables (not history blocks) can be migrated after the general
upgrade has been performed.
The scripts are created when you first run the database setup utility so that you can run them at any time.
The file path is:
To migrate your database
1. On a new Historian server, use SQL Management Studio to:
a. Delet e any empty Runtime database that was created as part of the installation.
b. Restore the old Runtime dat abase from a backup.
2. Run the Configurator.
3. In the left pane, select Hi storian and then select Server.
4. Configure the server. See "Configuring Dat abases and Data File Locations on page 43" for details.
Upgrading the Historian Version

Refer to Upgrading from a P revious V ersion on page 125 to see which versions can be directly upgraded
to Historian 2017 Updat e 3 SP1.
The existing Runtime and A2A LMDB databases are automatically migrated to during the installation,
preserving all existing settings and tag configuration.
History blocks created using a previous version of the Historian do not require any migration and can be
copied t o and used with Historian 2017 Update 3 SP1, as long as the tags they contain are present in the
Runtime database.
To upgrade the Historian
1. Back up the Runtime database.

2. Shut down and disable the Historian using the Management Console. Any remote IDAS nodes will
go into store-and-forward mode.
3. Run the System Platform installation program to perform the upgrade. For more information, see
Upgrading System Platform on page 58.
4. The installation program detects the previous version of the Runtime database and prompts you to
keep the existing database or recreate the new database.
5. If you re-create the database, existing Runtime database will not be re-named but will be overwritten
with a new Runtime database. If you do not re-c reat e the database, the existing database will remain
intact.
6. Finish the installation of the Historian.
7. Restart the computer.
8. Start the Historian. The Historian will start acquiring and storing the store-and-forward data from the
existing remote IDASs.
9. After the Historian Server node is upgraded, you can upgrade any remote IDAS nodes.
Migration of History Data Stored in SQL Server

The normal SQL Server tables in the Runtime dat abase contain configuration data and certain types of
history data. History dat a that is stored in the normal SQL Server tables includes:
 Data in the AnalogManualHistory, DiscreteManualHistory, and StringHist ory tables.
 Classic event and summary dat a, which is stored in the E ventHistory, SummaryHistory,
Summary Data, AnalogS napshot, DiscreteSnapshot, and StringS napshot tables.
These tables can contain hundreds of thousands of rows, if not millions of rows. Depending of the
amount of data to be migrat ed, migrating this data can take a few minutes to many hours, and in some
cases, days.
Important: You MUS T perform the database migration before the server goes back into production,
because the history table content will be truncated. Be sure that you have disk space equivalent to two
times the size of the Runtime database on the drive to which the history data will be migrated; otherwise,
the migration may fail. Back up the Runtime database with the migrated config uration data before
migrating the history data.

C HAPTER 8
Historian Client Requirements
In This Chapter
About the Historian Client ............................................................................................................ 127
Historian Client Components ....................................................................................................... 127
Requirements and Recommendations .......................................................................................... 128
Support for Operating System Language Versions ........................................................................ 128
About the Historian Client

You can use the Historian Client software to address specific dat a representation and analysis
requirements. The Historian Client soft ware maximizes the value of the data present in the Historian and
helps you organize, explore, analyze, present, and distribute process data in a variety of formats.
With the Historian Client software, you can:
 Explore data graphically to find import ant information
 Analyze data
 Develop and execute ad hoc queries against any data stored in the Historian database
 Visualize the current process state
Historian Client Components

The Historian Client software comprises of tools that eliminat e the need to be familiar with the SQL and
provides intuiti ve point-and-click interfaces to access, analyze, and graph both current and historically
acquired time-series data.
Desktop Applications
The Historian Client software includes the following stand -alone applications:
Historian Client Trend
 Allows plotting of historical and recent data over time
 Allows you to compare data over different time periods
Historian Client Query
 Allows you to query the Historian database
 Provides complex, built-in queries
 Eliminates the need to be familiar with the dat abas e structure or SQL
Microsoft Office Add-Ins

The Historian Client software includes the following add-ins for Microsoft Excel and Microsoft Word. The
add-ins support only 32-bit versions of these applications.

System Platform Installation Guide Historian Client Requirements
Historian Client Workbook

 Allows display and analysis of historical and recent data from a Historian database using the Excel
spreadsheet format
Historian Client Report
 Allows advanced reporting of historical and recent data from a Historian dat abas e using the Word
document format
ActiveX and .NET Controls

The aaHistClient Trend and aaHistClient Query controls provide the essential functionality of the Historian
Client Trend and Historian Client Query. You can use these controls in container applications, such as
®
InTouch HMI software, Visual Studio (Visual Basic .NE T or C#), and Internet Explorer. You can also use
Historian Client "building block" controls (such as aaHistClient TagPicker, aaHistCl ient TimeRangePicker,
and so on) in your custom applications.
Requirements and Recommendations

You must log on to the computer as an administrator to install the Historian Client software. Be sure that
you read the hardware and software requirements in the System Platform Readme before starting the
installation.
Support for Operating System Language Versions

The English version of the Historian Client software runs on the following operating system languages:
 English
 Frenc h
 German
 Japanese
 Simplified Chinese
Note: The SQL Server locale language must be the same as the operating system locale language.

C HAPTER 9
Historian Client Installation and
Configuration
The System Platform installation program allows you to install the Historian Client software. The System
Platform installation program copies the files from the setup DV D to the target computer.
For more information on the components installed, see Historian Client Components on page 127.
In This Chapter
About Historian Client Installation................................................................................................. 129
Using Historian Client Software with Roaming Profiles .................................................................. 129
Repairing the Historian Client Installation ..................................................................................... 130
Uninstalling Historian Client ......................................................................................................... 130
Upgrading from a Previous Version.............................................................................................. 130
About Historian Client Installation

Before installing the Historian Client soft ware, log on to the computer as an administrator. Before c opying
the software files, the System Platform installation progr am checks for the basic system prerequisites.
You can individually select or deselect features of Historian Client for installation. These are:
 Trend/Query Clients: This feature lets you view and analyze dat a and trends.
 Microsoft Office (32-bit) Add-ins: This feature installs Historian Client add-ins for Microsoft Word and
Excel. You must have a 32-bit version of these programs installed.
 PDF Doc uments
The System Platform installation program checks if a Microsoft Excel process is running. If Exce l is
running, a message appears informing you that an Excel process and the
aaHistClient ReportingService.exe service are running.
To continue with the installation, you need to manually stop the services and click Retry. Click Close if
you want to stop the installation.
Note: In some cases, depending upon the operating system and the prerequisite, you may have to
restart the system after the prerequisites are installed. In such cases, the setup automatically continues
after the restart.
For instructions on installing the Historian Client soft ware files, see Installing System Platform on page
23.
After the Historian Client software is installed on the computer, you must install the Langu age Packs
manually.
Using Historian Client Software with Roaming Profiles

If your network environment uses roaming user profiles, you must change a registry key so that changes
to any Historian Client software options are saved in the user profiles.

System Platform Installation Guide Historian Client Installation and Configuration
To save software options in the roaming user's profile, add a DWORD key named "EnableRoaming" to
the user's HKEY_CURRE NT_USE R\Soft ware\ArchestrA
\ActiveFactory registry folder and change its value to 1.
Repairing the Historian Client Installation

You can use the System Platform installation program to repair corrupt files of the installed features. For
more information, see Repairing an Installation on page 56.
Note: You can also use the standard Windows Uninstall/Change Programs feature from the Control
Panel to repair the Historian Client software installation.
Uninstalling Historian Client

You can use the System Platform installation program to remove the Historian Client software that exists
on your computer. For more information, see Uninstalling System Platform on page 57.
Note: You can also use the standard Windows Uninstall/Change Programs feature from the Control
Panel to remove the Historian Client software installation.

You can upgrade to Historian 2017 Update 3 SP1 from:
 Historian 2014 R2 (version 11. 6.12100) SP1 (and applicable patches).
 Historian 2017.
 Historian 2017 Update 1.
You should upgrade the Historian Server before upgrading Historian remote IDAS nodes. Remote IDAS
nodes that are not upgraded will remain fully functional. However, it is strongly recommended that you
upgrade them to Historian 2017 Updat e 3 SP1 to incorporate minor improvements and simplify further
upgrades and maintenance.
If you have been using replication, when upgrading historian nodes, upgrade the tier -2 historian node
first and then the tier-1 historian node.
Upgrading From a Version Earlier Than Historian 2014 R2
You must make some changes manually if you need to upgrade from a version of Historian prior to
version 2014 R2. When you run the Configurator, it generates SQL scripts that you can use for manually
migrating older releases.
To upgrade from an earlier version of Historian (before v.2014 R2)
1. Install Historian 2017 2017 Update 3 SP1 and run Configurator.
2. From the System Management Console, shutdown and disable Historian.
3. Locate SQL scripts that you'll need for intermediate migration in this folder:
C:\ProgramData\ArchestrA\Hi storian\Install\Scripts
4. From SQL Server Management Studio:
a. Drop the Runtime database.
b. Restore a backup of the Runtime from your previous version of Historian.

Historian Client Installation and Configuration System Platform Installation Guide
5. Disable any triggers or constraints that would prevent schema changes. This prepares your
database for changes.
6. Run the scripts you need to update Historian.
If you are upgrading from a much older version, you may have to run scripts to incrementally up grade
versions.Run the scripts in the order they appear (when sorted alphanumerically).
7. Restore any changes (triggers and other constraints) that you made to settings in step #5.
8. Shut down the old server's remote IDAS.
9. From the new server, force an update to the remote IDAS configuration.

A PPENDIX A
Using Silent Installation
System Platform supports silent (command line) installation. This feature enables you to install System
Platform products without user interaction.
Important: If prerequisite software is required for the System Platform products y ou are
installing, all prerequisites must be installed before starting silent installation.
Prerequisite software includes .NE T Framework and SQL Server. Details about prerequisite software is
provided in S ystem Platform Prerequisites on page 14. See SQL Server Requirements on page 69 for
additional information about support ed versions of SQL Server.
Setup.exe is run from the command line and accepts as an argument the name and path of a response
file containing pre-scripted responses to System Platform installation prompts.
Important: Use silent installation only to install a new system or upgrade an existing one. Adding or
removing components during an upgrade is NOT supported.
In This Appendix
Starting Silent Installation ............................................................................................................ 133
Using Response Files ................................................................................................................. 135
Creating a Response File ............................................................................................................ 136
Response File Samples .............................................................................................................. 137
Response File Entries to Configure the License Server ................................................................. 141
Response File Entries to Configure the System Management Server ............................................. 142
Starting Silent Installation

To run silent installation, open a command prompt using Run a s administrator. The basic syntax of the
silent installation command consists of the full pat h to the setup.exe file (typically the DV D drive
designation on your local computer), the command line switch for silent installation, and the full path to
the response file.
To see descriptions of the switches and options available, enter /? after the setup command.
D:\setup.exe /?
Setup.exe will install products in UI and Silent mode.
Setup.exe [/silent] [/silentmodify] [/silentrepair] [/silentuninstall]

[/silentnoreboot] [/silentpatch] [/mingui] [responsefile] [/nowait]
/silent specifies the installation is silent Install

and doesn't show UI.
/silentmodify specifies the installation is silent modify
/silentrepair specifies the installation is silent repair
/silentuninstall specifies this is silent uninstall.
/silentnoreboot specifies the installation is silent Install

System Platform Installation Guide Using Silent Installation
and doesn't show UI with no reboot.

/silentpatch specifies the installation is silent patch Install.
/mingui specifies the installation is silent with mingui.
/nowait specifies with silent Install/modify/repair/uninstall
with immediate return to command line.
responsefile specifies the response file.
Examples:
setup.exe /silent responsefile.txt
setup.exe /silentmodify responsefile.txt
setup.exe /silentrepair {productguid}
setup.exe /silentrepair {productguid}.{ownerguid}
setup.exe /silentuninstall {productguid}
setup.exe /silentnoreboot responsefile.txt
setup.exe /silentpatch
setup.exe /mingui responsefile.txt
setup.exe /silent responsefile.txt /nowait
setup.exe /silentmodify responsefile.txt /nowait
setup.exe /silentrepair {productguid} /nowait
setup.exe /silentrepair {productguid}.{ownerguid} /nowait
setup.exe /silentuninstall {productguid} /nowait
Silent installation syntax:
<DVD>:\setup.exe /silent "<path\response-file-name>"
Note that the full filespec of the response file (filename plus location of file) must be included. For
example:
<DVD>:\setup.exe /silent "C:\docs\WSPInstall\response.txt"
The /silent switch completely disables the graphical user interface of S etup.exe. There is no input from or
feedback to the end user. However, the installation will output progress to a log file. The log is usually
found here:
C:\Program Files (x86)\Common Files\ArchestrA\Install\
{<FolderName>}\ILog<timestamp>.log
Silent installation with minimal GUI syntax:
D:\setup.exe /MINGUI <path\response-file-name>
Running setup with the /MINGUI switch will cause setup to install wit hout any input from the end user, but
it will display the progress of the installation on screen.
Silent installation with automatic system restart di sabled:
D:\setup.exe /silentnoreboot <path\response-file-name>
Running with the /silentnoreboot switch will keep the command window open so you can preserve
messages from the installation process. A manual reboot will be required after installation completes.
Silent installation command-line help:
D:\setup.exe /?
Running setup with the /? switch will display the silent installation command-line help.
User Permissions
In addition using the Run a s administrator option to start silent installation, you should also be a SQL
Server admin. If you do not have SQL Server admin privileges, you can still use silent install if yo u
properly configure the System Platform response files to invoke the credentials of an existing SQL
Server admin. See Configure SQL S ysAdmin Permissions on page 135 for more information. For
general information about response files, see Using Response Files on page 135.

Using Silent Installation System Platform Installation Guide
Configure SQL SysAdmin Permissions

The information in this section applies only if the logged-in Windows user for installation does not have
SQL SysAdmin permissions. If this is the case, use one of the following options.
Option 1: Use SQL authentication (SA). Add t he following properties to the response file and configure
them as indicated:
ConfigureSQL.SUserName=<SA User>
ConfigureSQL.SPassword=<SA Password>
ConfigureSQL.SQLAuthentication=true
Option 2: Provide a Windows User who has SQL SysAdmin permi ssions. Add the following
properties to the response file and configure them as indicated:
ConfigureSQL.SUserName=<DOMAIN\USER>
ConfigureSQL.SPassword=<PASSWORD>
ConfigureSQL.SQLAuthentication=false
Using Response Files

Response files are plain text files. They specify which System Platform products, and even which
features of a product that Setup.exe will install. For example, one response file could be used to install
the components for a run-time environment. A different response file might be used to install the
components for a development server.
Response files can install more than one product at a time, enabling you to install all the necessary
products for a given role.
Because the user will get little feedback on error conditions, it is necessary for the user to perform the
following checks before installing via command line:
1. Ensure that the operating system is a supported version with all of the correct service packs.
2. Ensure that the SQL Server is a supported version.
3. Ensure that the user running the install has administrator rights.
4. Ensure that SQL Server SysAdmin permissions are configured. See Configure SQL S ysAdmin
Permissions on page 135 for more information.
Any issues that would stop a normal GUI-based installation, such as the presence of incompatible
software, will als o prevent successful completion of a command -line installation. You can keep the
command prompt open during installation by specifying the / silentnoreboot switch. This will let you view
messages related to installation issues. Installation messages are lost when the system restarts. With
the /silentreboot switch, you will need to manually restart the system after installation completes. If you
allow the system to restart automatically, as it will if you us e the / silent switch, you can s earc h the log file
for error conditions that may have stopped the installation from completing successfully.
Note: If the GUI installer would install any necessary prerequisites, the command line installer will als o
install these items.
All the sample response files contain information to create the ArchestrA User Account for system
communication. If another System Platform product was previously installed and the the ArchestrA User
Account was already created, subsequent installations will not create another ArchestrA User. The
original ArchestrA User will be ret ained.
For example, under those conditions, Setup.exe ignores the following lines in the response file:
AdminUserForm.SUserName=ArchestrAUser
AdminUserForm.SPassword=<password>
AdminUserForm.SCreateLocal=true

A good approach for testing is to first run the setup.exe in GUI mode on a typical computer and confirm
that no incompatibilities exist that would stop the installation, then cancel and run by command line.
Note: If the GUI-based installation requires a system restart after the installation is complete, installing
by command line will also require a system restart. Using the / silent switch allows the system to restart
automatically. The / silentnoreboot switch suppresses the automatic restart, but will require a manual
restart.
Creating a Response File

Response files consist of an INS TA LL section and a CONFIGURA TOR section. See Response File
Samples on page 137 for examples that you can use after making minor edits.
Install Section
The INS TALL section defines the items that would be selected through the GUI installation dialog
windows. These are:
 The root installation directory. The default path is C:\Program Files (x86).
o Example:
FeatureForm.SInstallDir=C:\Program Files (x86)
 The ArchestrA user account (name and password), used for inter -node and inter-product
communications.
o Example:
AdminUserForm.SPassword=Password123
 The components and related requirements that will be installed. You can specify by inclusion or
exclusion:
o Install by inclusion example:
FeatureForm.SFeatureList=Wonderware System Platform.ASBRuntime,Application
Server.Bootstrap,Application Server.IDE
o To specify products by exclusion, first add ALL products with an inclusion statement, then list the
ones that should be left out.
Install by exclusion example:
FeatureForm.SFeatureList=ALL
FeatureForm.SExcludeFeatureList= InTouch Access Anywhere Secure
Gateway.SecurityServer_Files,InTouch Access Anywhere Authentication
Configurator Section
The CONFIGURA TOR section defines the components that would be configured through the
Configurator GUI. These include the following:
 Product licensing example (to install a license server, define the license server name and port
number):
AVEV A Enterpri se Licensing.LicAPI2. NewServerName =SE_LICE NSE_SERVE R_NAME
AVEV A Enterpri se Licensing.LicAPI2. NewPortNumber=55555
 ASB runtime examples. These entries are used to configure the System Management Server.
Arche stra Service Bus. ASBRuntime.HttpPort = 80

Arche stra Service Bus. ASBRuntime.HttpsPort = 443

Arche stra Service Bus. ASBRuntime.ManagementServerPort = 443
Arche stra Service Bus. ASBRuntime.ManagementServerName = MachineName
Arche stra Service Bus. ASBRuntime.AsbManagedCertificates = true
Arche stra Service Bus. ASBRuntime.BindingCertificateThumbprint = thumbprint
(optional required if AsbManagedCertificat es = false, otherwise remove this parameter)
Arche stra Service Bus. ASBRuntime.UserName = username
Arche stra Service Bus. ASBRuntime.Password = password
 Sentinel examples. These entries are used to configure the Sentinel Manager and Agent.
Sentinel Agent Install Manager.Sentinel Manager.AgentServerName =ServerName
Sentinel Manager.SMTP.SmtpServerNameorIp = MachineName or IP Address
Sentinel Manager.SMTP.SmtpServerPort = portNo
Sentinel Manager.SMTP.SmtpServerSecured = false (set true, if user c redentials are required
to access the SMTP server)
Sentinel Manager.SMTP.SmtpUserName = username (if SMTP Server is secured)
Sentinel Manager.SMTP.SmtpPassword = password (if SMTP Server is secured)
Sentinel Manager.SMTP.SmtpFromRecipientEmailID = email address (for sending alerts
from Sentinel Manager)
Sentinel Manager.SMTP.SmtpRecipientEmailID = email address (for receiving alerts from
Sentinel Manager. Use a semicolon to separate multiple addresses )
 Historian examples. These ent ries are used to configure the Historian.
Hi storian.Historian.SilentTCPPort=32568
Hi storian.Historian.SilentchkBoxAutoStartHi storian=true
Hi storian.Historian.SilentDBOption=REBUILD
Hi storian.Historian.SilentDBPath=C:\Program Files\Microsoft SQL
Server\MSSQL10.SERVER\MSSQL\DA TA
Hi storian.Historian.SilentDataPath=C:\Historian
Hi storian.Historian.SilentSQLUserName =SQLUserName
Hi storian.Historian.SilentSQLPassword=SQLUserPW
Hi storian.Historian.SilentBlockStorageMode =1
Hi storian.Search.SilentSearchInstall=true
Hi storian.Extensions.SilentExtensionInstall=true
Response File Samples

The res ponse file samples are provided as .txt files on the installation DVD within the following directory
path:
\InstallFiles\ResponseFiles\Samples\
These samples can be used as templates to initiate the installation of certain products or features during
the silent install process.

To use the response file samples as templates

1. In Notepad or a similar text editor, open the appropriate response .txt file from the installation DVD.
Refer to the Role-B ased Response Files on page 138 or the Product-Based Respons e Files on page
140 sections to determine the correct .txt file to use.
2. Edit the response file as necessary.
a. Edit the Us erName, Password and Creat eLocal (true or false) responses. The t emplat es contain
sample responses on these lines. Delete the sample responses, located to the right of the equal
sign (=), and replace with your own response.
b. If you install Historian components, provide the SQL Server user name and password.
3. Save the file to a directory on your local computer. Note the path and full name of the file.
4. From the command line, type the install command and provide the path and filename of the response
file you want to use.
Example: D:\setup.exe /silent c:\Documents\DevNode.txt.
In this example, the setup.exe file is in the root directory of the DVD, and the development node
response file is on the local C: drive in the specified directory.
5. Press Enter to start the specified installation.
Role-Based Response Files

The following response files install System Platform products to perform the functions of specific roles.
All response files listed here can be found on the installation DVD under
InstallFiles\ResponseFiles\Samples.
Response File Description
All.txt Installs every product included with System Platform, except

InTouch Access Anywhere Secure Gat eway and InTouch Access
Anywhere Authentication Server. Since this response file installs the
Galaxy Repository, the License Server, System Management
Server, and Sentinel Manager are also installed.
See sample file, below
Historian Client Node.txt Installs the components required to connect to an existing Historian
Server, analyze the dat a, and provide Application Server run-time
components.
Historian Server Node.txt Installs the components required to host a Historian server, analyze
the data with a Historian Client, and provide Applic ation Server
run-time components.
Remote System Platform Installs the components required to connect to an existing
Development Client.txt development server in order to develop and test InTouch and
System Platform applications.
Runtime Client.txt Installs the components required to run InTouc h HMI, the Historian
client, and ArchestrA object server run time.

System Platform Installs the components required to host the development server, in
Development Server.txt order to develop and test InTouch HMI and InTouc h OMI
applications.
This response file includes the Galaxy Repository, Licens e Server,
Sentinel Manager, and System Management Server.
Sample Role-Based Response File

All.txt
<responsefile>
<install>
FeatureForm.SFeatureList=ALL
FeatureForm.SExcludeFeatureList=InTouch Access Anywhere Secure
Gateway.SecurityServer_Files,InTouch Access Anywhere Authentication
Server.AuthenticationServer_Files,InTouch Access Anywhere Authentication
Server.Languages,InTouch Access Anywhere Authentication
Server.WebServer2,InTouch Access Anywhere Authentication
Server.Common_files_2,InTouch Access Anywhere Secure
Gateway.AccessNowFiles,InTouch Access Anywhere Secure
Gateway.Common_Files,InTouch Access Anywhere Secure Gateway.WebServer,InTouch
Access Anywhere Secure Gateway.Admin,InTouch Access Anywhere Secure
Gateway.ESG,InTouch Access Anywhere Secure Gateway.View,InTouch Access Anywhere
Authentication Server.Admin2,InTouch Access Anywhere
Server.HTML5_Server_Files,InTouch Access Anywhere
Server.HTML5ClientFiles,InTouch Access Anywhere Server.FileTransfer,InTouch
Access Anywhere Server.LicenseServer,InTouch Access Anywhere
Server.Printing,InTouch Access Anywhere Server.ServerConfiguration,InTouch
Access Anywhere Server.TSAgent
</install>
<configurator>
Platform.LicAPI2.NewServerName=SE_LICENSE_SERVER_NAME
AVEVA Enterprise Licensing Platform.LicAPI2.NewPortNumber=55555
Historian.Historian.SilentTCPPort=32568
Historian.Historian.SilentchkBoxAutoStartHistorian=true
Historian.Historian.SilentDBOption=REBUILD
Historian.Historian.SilentDBPath=C:\Program Files\Microsoft SQL
Server\MSSQL10.SERVER\MSSQL\DATA
Historian.Historian.SilentDataPath=C:\Historian
Historian.Historian.SilentSQLUserName=
Historian.Historian.SilentSQLPassword=
Historian.Historian.SilentBlockStorageMode=1
Historian.Search.SilentSearchInstall=true
Historian.Extensions.SilentExtensionInstall=true
Common Platform.ASBRuntime.HttpPort=80
Common Platform.ASBRuntime.HttpsPort=443
Common Platform.ASBRuntime.ManagementServerPort=443
Common Platform.ASBRuntime.ManagementServerName=MachineName (input the
Managment Server name if need to configure to this Community Management Server)
Common Platform.ASBRuntime.AsbManagedCertificates=true

Common Platform.ASBRuntime.BindingCertificateThumbprint=thumbprint (optional

required if AsbManagedCertificates = false, otherwise remove this parameter)
Common Platform.ASBRuntime.UserName=username
Common Platform.ASBRuntime.Password=password (UserName and Password parameters
are not required if the current logged in user is authenticated to access the
Management Server, you can remove the parameters if they are not required)
Sentinel Agent Install Manager.Sentinel Manager.AgentServerName=ServerName
Sentinel Manager.SMTP.SmtpServerNameorIp = MachineNameOrIp
Sentinel Manager.SMTP.SmtpServerPort = portNo
Sentinel Manager.SMTP.SmtpServerSecured = false (set true, if the SMTP server
needs user credientials to access the SMTP server)
Sentinel Manager.SMTP.SmtpUserName = username
Sentinel Manager.SMTP.SmtpPassword = password (UserName and Password parameters
are not required, if the SMTP server needs user credien tials to access the SMTP,
you can remove the parameters if they are not required)
Sentinel Manager.SMTP.SmtpFromRecipientEmailID = from_EmailID
Sentinel Manager.SMTP.SmtpRecipientEmailID = receipientEmailID (provide one or
multiple Email Id's seperated by semi colon(;)
</configurator>
</responsefile>
Product-Based Response Files

The following response files install the selected product or products of System Platform. All response
files listed here can be found on the installation DVD under InstallFiles\Re sponseFile s\Samples.
Application Server and Installs the components needed for Application Server and InTouch
InTouch OMI.txt OMI run-time.
Application Server Installs the components needed for Application Server development.
Development.txt
Application Server Galaxy Installs components needed for the Galaxy Repository. Since this
Repository.txt response file installs the Galaxy Repository, the License Server,
System Management Server, and Sentinel Manager are also
installed.
Historian.txt Installs the components needed for the Historian.
Historian Client.txt Installs the components needed for the Historian Client.
InTouch Access Anywhere Installs the components needed to run InTouch and InTouc h Access
and InTouch Runtime.txt Anywhere.
See sample response file, below.
InTouch Access Anywhere Installs the InTouch Access Anywhere Aut hentication Server. No
Authentication Server other components are installed.
InTouch Access Anywhere Installs the InTouch Access Anywhere Sec ure Gateway. No other
Secure Gateway.txt components are installed.

Security Server Installs the ASB Management Server and ASB Runtime
components. No other components are installed.
Sentinel Manager Installs the Sentinel Manager and Sentinel Agent.
Wonderware Application Installs the components needed for Application Server run time and
Server.txt development. Since this response file installs the Galaxy Repository,
the License Server, System Management Server, and Sentinel
Manager are also installed.
Wonderware InTouc h.txt Installs the components needed for InTouc h run time and
development. Since this response file installs the Galaxy Repository,
the License Server, System Management Server, and Sentinel
Manager are also installed.
Sample Product-Based Response File
Application Server and InTouch OMI.txt
<responsefile>
<install>
FeatureForm.SFeatureList=Wonderware System Platform.ASBRuntime,Application
Server.Bootstrap,Application Server.AcfBaseApplication,Application
Server.AcfMobileAccess,Historian Client.Medusa,Sentinel System Monitor.SIM
</install>
<configurator>
Common Platform.ASBRuntime.HttpPort=80
Common Platform.ASBRuntime.HttpsPort=443
Common Platform.ASBRuntime.ManagementServerPort=443
Common Platform.ASBRuntime.ManagementServerName=MachineName (input the
Managment Server name if need to configure to this Community Management Server)
Common Platform.ASBRuntime.AsbManagedCertificates=true
Common Platform.ASBRuntime.BindingCertificateThumbprint=thumbprint (optional
required if AsbManagedCertificates = false, otherwise remove this parameter)
Common Platform.ASBRuntime.UserName=username
Common Platform.ASBRuntime.Password=password (UserName and Password parameters
are not required if the current logged in user is authenticated to access the
Management Server, you can remove the parameters if they are not required)
Sentinel Agent Install Manager.Sentinel Manager.AgentServerName=ServerName
</configurator>
</responsefile>
Response File Entries to Configure the License Server

You can configure licensing through the silent install process by using a respons e .txt file. To configure
the License Server, add the following entry to your .txt response file:
<configurator>


</configurator>
Replace "SE_LICE NSE_SE RVER_NAME" with the name of your Licens e Server. If you need change
the port number, replace the default entry "55555" with the new port number.
Response File Entries to Configure the System Management

Server
The System Management Server is us ed to establish machine trust between nodes. See Configuring the
System Management Server on page 34 for additional information. To configure the System
Management Server silently, add the following ent ries to your .txt response file:
<configurator>
Archestra Service Bus.ASBRuntime.HttpPort = 80
Archestra Service Bus.ASBRuntime.HttpsPort = 443
Archestra Service Bus.ASBRuntime.ManagementServerPort = 443
Archestra Service Bus.ASBRuntime.ManagementServerName = MachineName
Archestra Service Bus.ASBRuntime.AsbManagedCertificates = true
Archestra Service Bus.ASBRuntime.BindingCertificateThumbprint = thumbprint
(optional required if AsbManagedCertificates = false, otherwise remove this
parameter)
Archestra Service Bus.ASBRuntime.UserName = username
Archestra Service Bus.ASBRuntime.Password = password (UserName and
Password parameters are not required if the current logged in user is
authenticated to access the Management Server, you can remove the parameters
if they are not required)</configurator>
Edit the port numbers if nec essary. Replace the Management Server Name with the name of the node
where the ASB License Server is installed. If you do not want the Management Server to manage
certificates, set the AsbManagedCertificat es parameter to false. Note that if AsbManagedCertificate s is
false, you must enter the thumbprint value for the BindingCertificateThumbprint parameter. For
information about acquiring a certificate thumbprint, see Using HTTPS Instead of HTTP for Historian
Client, InSight, and REST APIs on page 121.
If you have not have an ArchestrA network user already configured, you must add the user name and
password. If the ArchestrA network user already exists, the username and password paramet ers are
ignored.

A PPENDIX B
Single Product Installation
You can create an alternative installation media source if you are installing only Historian, Historian
Client, or the Application Server runtime, and you want to reduce net work usage. This alternative
installation source will be much smaller t han t he full set of installation files, and thus will be easier to send
to remote loc ations. This is of particular value if your net work connection to the remote site is slow or
unreliable, and any of the following, or similar circumstances, apply:
 You have multiple nodes at a remote site on which you want to install only Historian, Historian Client,
or the Application Server runtime.
 A firewall at the remote site restricts most off-site access, and having a local copy of the installation
files is easier to manage than having to modify the firewall.
 Installing from a WAN-based share is impossible due to the speed or reliability of the network
connection.
With this procedure, you will:
1. Create a new installation source that contains a subset of the installation files contained on the
System Platform installation DVD.
2. Install Historian, Historian Client, or the Application Server runtime from this subset of files.
Copying the files, rather than installing from a remote location, eliminates the possibility of a time -out
during installation.
In This Appendix
Guidelines for Creating a Compact Installation Source .................................................................. 143
Preparation for Installing a Single Product .................................................................................... 144
Creating the Installation Source and Installing the Selected Component ......................................... 146
Guidelines for Creating a Compact Installation Source

Important: This process can only be used for installing Historian, Historian Client, or the Application
Server runtime. Other product configurations are not supported.
The work flow for creating the compact installation source is:
1. Copy the entire contents of the System Platform installation DV D.
2. Delet e language and product components that are not needed.
3. Copy the directory containing the remaining com ponents to either:
 To the node where you will install the product.
 To a CD or DVD to be used as the installation disk.
When you run the installation program, components that were deleted will show as disabled (gray ed-out)
and unavailable for selection.

System Platform Installation Guide Single Product Installation

Do not delete folders for products that are already installed. The upgrade process will not complete if you
do not upgrade all products previously installed on the node. For example, if both Historian and Historian
Client are installed on the node, you must upgrade both.
Preparation for Installing a Single Product

To install Historian, Historian Client, Application Server, or InTouch, you can choose not to install or copy
unnecessary files.
 The root directory contains the installation program (setup.ex e) and several document files. Two files
in the root directory are absolutely required: Autorun.inf (1 KB) and Setup.exe (1.8 MB ). The
remaining files are documents: the System Platform Installation Guide (3 MB), the System Platform
Virtual Implement ation Guide (3.5 MB), the S ystem Platform Getting Started Guide (2.5 MB), and the
System Platform Readme (260 KB).
 The entire InstallITK folder (about 7.5 MB) is required.
 The following table shows which subfolders in the InstallFiles folder are required for Historian,
Historian Client, Application Server (including InTouch OMI run time), and InTouch HMI
development and run time. You can delete folders that are not required for the product you are
installing. The size of the resulting set of folders is approximate and is provided for reference.
 There are about 17 files in the InstallFiles folder root, with a total size of about 5 MB. Three of these
are document files (21_CFR_P art11_Deployment _Guide.pdf, ReadMe.html,
WSP_Install_Guide.chm), whic h total about 5 MB. These files are not required for installation .
The following table shows which folders can be deleted and which must be retained for each of the
product installations. The folder sizes listed are approximate.
For InTouch, only the language folder that is being installed is required (CD -Intouch = English).
Approx InTouch
InstallFiles Folder Folder Hi storian Application (Run time only or
(Component) Size Hi storian Client Server run time and
development)
CD-ApplicationServer 1 GB Required Ok to delete Required Required
CD-ASBFramework 150 MB Required Required Required Required
CD-Gateway 70 MB OK to delete OK to delete OK to delete Ok to delete
CD-Historian 495 MB Required Ok to delete Ok to delete Ok to delete
CD-HistorianClient 50 MB Ok to delete Required Required Required
CD-Intouch 580 MB Optional Ok to delete Ok to delete Required for

English
If InTouch is required, delete language folders that are not needed (CD-InTouch = English). CD-InTouchWebClient is
required whenever InTouch is installed.
CD-IntouchFrench 610 MB Optional Ok to delete Ok to delete Required for

Frenc h
CD-IntouchGerman 605 MB Optional Ok to delete Ok to delete Required for
German
CD-Intouch Japanese 615 MB Optional Ok to delete Ok to delete Required for
Japanese

Single Product Installation System Platform Installation Guide
InTouch
Approx
development)
CD-Intouch S Chinese 615 MB Optional Ok to delete Ok to delete Required for

Chinese
CD-IntouchWebClient 100 MB Optional Ok to delete Ok to delete Required
CD- InTouchWebClient is required whenever InTouch is installed.
CD-Language Assistant 100 MB Optional Ok to delete Ok to delete Optional
CD-LicAPI 60 MB Required Required Required Required
CD-Licensing 70 MB Required Required Required Required
CD-NGVisualization 250 MB Ok to delete Ok to delete Required Required
CD-OIEngine 60 MB Required Required Required Required
CD-OIGA TEWAY 20 MB Required Required Required Required
CD-SentinelAgent 5 MB Required Required Required Required
CD-SentinelServer 30 MB Ok to delete Ok to delete Ok to delete Ok to delete
CD-Server 45 MB Required Ok to delete Ok to delete Ok to delete
External 3 MB Required Required Required Required
Redist 1.3 GB See note See note See note See note
(DOTNE T) (DOTNE T) (DOTNE T) (DOTNE T)
 DOTNE T 65 MB Optional Optional Optional Optional
If .NET version 4.7.2 or higher is already installed, you can remove the DOTNET folder from Redist.
 MDAC 5 MB Required Required Required Required
 MSI4.5 6 MB Required Required Required Required
 MSOLEDBS QL 7 MB Required Required Required Required
 PreReqInstaller 100 KB Required Required Required Required
 Safenet 10 MB Required Required Required Required
 SQL2014E XP RSP2 1.1 GB Ok to delete Ok to delete Ok to delete Ok to delete
See Note, below, about removing subfolder SQL2014EXPRSP2 from Redist.
 VC10SP 1 20 MB Required Required Required Required
 VC90SP 1 5 MB Required Required Required Required
 VC2012U4 15 MB Required Required Required Required

System Platform Installation Guide Single Product Installation
InTouch
Approx
development)
 VC2013U4 15 MB Required Required Required Required
 VC2017 30 MB Required Required Required Required
ResponseFiles 100 KB Required Required Required Required
Support 500 KB Required Required Required Required
UpgradeSupport 40 MB Required Required Required Required
Note: The Redist folder contains SQL Server Express in folder SQL2014E XP RSP2. You can remove
this folder if:
- You are installing Historian Client. SQL Server is not required.
- You are installing A pplication Server, InTouch, or Historian, and SQL Server is already installed.
See SQL Server Requirements on page 69 for information about supported versions of SQL Server.
Optional Folder for Historian

The CD-InTouch folder contains a database purge utility that Historian uses (this utility is not called when
block-bas ed event history is utilized). Without this folder, Historian cannot purge the A2A LMDB alarm
database and an error will be generated (this does not occur with block -based history). If you are
installing Historian Client only, this utility is not called and the folder can be deleted without any i ssues.
Note: If you are installing Historian and the CD-Intouch has been deleted, you will not be able to purge
the A2ALMDB alarm database and an error will be generated (does not apply if you are using
block-bas ed history). However, the installation will complete successfully.
Creating the Installation Source and Installing the Selected

Component
To create an installation source
1. Copy the entire contents of the System Platform installation DV D to a local folder on your computer
or to a net work share location.
This location will be used to prepare for the installation or upgrade of the product you are installing.
Important: You must copy the entire DVD. The root directory from the DVD and all files in it must be
in place and completely intact.
2. Navigate to the location where you copied the DV D. Delete the files, components and language
folders that you do not need.
Now you are ready to install or upgrade the product(s) using either of the methods described below.
To install or upgrade a single product
Direct installation from the copy location (install locally or on a different net work node):
1. Remove the original System Platform installation DV D from the drive.

Single Product Installation System Platform Installation Guide
Important: When you run setup.exe, it checks for the System Platform installation DVD. If the
installation DV D is available, it will be used instead of the copy location.
2. Navigate to the copy location.

3. Make sure you have deleted the folders you do not need.
4. Run setup.exe. Components that were deleted will be grayed -out and unavailable for installation.
5. If this is a new installation (not an upgrade), select the target location when you are prompted.
Installation from a CD or DV D:
1. Create a CD or DV D from the copy location after deleting the folders you do not need.
2. Run setup.exe from the CD/DV D on each node. Components that were deleted will be grayed -out
and unavailable for installation.

Index
configuring products • 32
1
16 Pen Trend • 23 D
database
A configuring • 43
A2ALMDB database • 95 disk space requirements • 95
aaAdministrators group • 64 disk sizing • 94
aaConfigS QL • 65 disk space
aaGalaxyOwner user account • 64
history blocks • 96
acquistion
planning • 95
loading • 101
ActiveE vent • 118
ActiveX and .NE T Cont rols • 128 E
aaHistClientQuery • 128 Enhanced Security Mode • 65
event data
aaHistClient Trend • 128
Antivirus Software • 120 migrating from older versions • 126
Application Server
hardware requirements • 76 F
user account requirements • 22 fault-tolerant servers • 93
ArchestrA user account
requirements for use with Application G
Server • 22
Galaxy database, migrating • 78
ASBService • 69
Galaxy Repository
ASBSolution • 69
upgrading • 76
upgrading with the Bootstrap • 73
B
upgrading with the Bootstrap and IDE • 73
Bootstrap
upgrading • 73
building block controls
H
hardware recommendations
aaHistClient TagPicker • 128
storage • 95
aaHistClient TimeRangePicker • 128
Historian Client • 127
Historian Dat abase Export/Import Utility
C requirements • 93
Change Net work Account utlity • 63 history blocks
common components • 84, 119
disk space requirements • 96
configuration utility • 43
history data

System Platform Installation Guide Index
disk space requirements • 96 Microsoft SQL Server
migrating from older versions • 125 installation • 117

Holding database
disk space • 95 N
named pipes • 117
I network cards • 102
network protocol • 103
IDASs
networking • 102
installing • 118
NTFS • 95
performance • 101
requirements • 93
O
security • 94 operating system
IDE • 78
non-English • 103
upgrading • 78
upgrading • 76
upgrading with the Bootstrap and Galaxy
Repository • 73
InBatch • 104 P
installation • 117 performance • 100
about • 129 examples • 104

modifying • 55 IDASs • 101
physical memory • 91
repairing • 56
port
silent • 133
SQL Server • 71
SQL Server • 117
port, non-default
Wonderware Historian • 117
SQL Server • 71
Wonderware System Platform • 23 process net work • 102
InTouch products
Window Viewer • 104 configuring • 32
protocols • 103
L recommendations • 102
LAN • 102
legacy mode • 65 R
legacy software • 84
RAID • 95
License Viewer • 119
repair • 130
licensing • 85
loading
Wonderware Historian Client • 130
requirements • 76, 91, 128
disk space • 95
M
Historian Database Export/Import Utility • 93
Management Console • 118
Manufacturing Execution Module • 104 IDASs • 93
memory requirements • 91, 100 System Management Console • 93
Microsoft Client Utilities • 117 Wonderware Historian • 91

Index System Platform Installation Guide
reserved names
system • 69 T
response files • 135
TCP/IP • 102, 117
retrieval tiered historian
loading • 101
sizing • 110
roaming profiles • 129
Runtime database
disk space • 95
U
uninstall
migration • 125
Wonderware Historian Client • 130
Wonderware System Platform component •
S 57
SCSI • 95 upgrade
security
basic steps • 76
modes • 65
Galaxy Repository • 76
remot e IDASs • 94
IDE • 78
silent installation • 133
software requirements • 76 operating system • 76
IDASs • 93 redundant pairs • 80
System Management Console • 93 run-time nodes • 79
Wonderware Historian • 91 SQL Server • 76

SPCPro • 23, 104
SQL Server V
incompatible version installed • 71 virtual memory • 91
SQL Server • 71, 76, 117
SQL Server language • 128 W
SQL Server, not found • 70 WAN • 102
SQL Server, untested version installed • 71 Wonderware Historian
versions • 70 components • 118
storage installation • 119
disk sizing • 94 loading • 101
hardware recommendations • 95 memory requirements • 91, 100
loading • 101 repair • 130
SuiteLink • 102 requirements • 91
summary dat a
upgrading • 130
migrating from older versions • 126 Wonderware Historian Client Components
system
components • 127
sizing • 104
Query • 127
System Management Console
Report • 127
installing • 118
Trend • 127
requirements • 93
Workbook • 127
Wonderware System Platform • 23

System Platform Installation Guide Index

WSP Install Guide

Uploaded by

Document Informationclick to expand document informationWSP Install Guide

Document Informationclick to expand document information

Copyright:

Available Formats

WSP Install Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WSP Install Guide

Uploaded by

Copyright:

Available Formats

System Platform

Version 2017 Update 3 SP1

Version 2017 Update 3 SP1 3

Chapter 2 Security and Permissions ................................................................................ 63

Chapter 3 Configuring SQL Server ................................................................................... 69

Chapter 4 Application Server Upgrade............................................................................. 73

Chapter 5 InTouch HMI Requirements and Prerequisites ............................................ 85

Chapter 6 Historian Server Requirements and Recommendations ............................. 91

4 Version 2017 Update 3 SP1

Planning for Disk Space Requirements ............................................................................... 95

Historian Server Installation and Configuration ............................................................... 117

Version 2017 Update 3 SP1 5

About Database Migration................................................................................................ 125

Historian Client Requirements ........................................................................................... 127

Historian Client Installation and Configuration................................................................. 129

Using Silent Installation ....................................................................................................... 133

Single Product Installation .................................................................................................. 143

Index ....................................................................................................................................... 149

6 Version 2017 Update 3 SP1

Preparing for System Platform Installation

Important Notice for for Highly Secured Environments (TLS 1.2

Version 2017 Update 3 SP1 7

License Installation and Activation

8 Version 2017 Update 3 SP1

The License Manager opens in your brows er.

Sentinel Manager and Agent Installation

Version 2017 Update 3 SP1 9

Operating System Minimum Requirements

Minimum Required Operating System Version

Product Client OS (x86 and x64) Server OS (x64 only)

System Sizing Guidelines

10 Version 2017 Update 3 SP1

CPU HD Screen Network

Server Nodes: for Historian Server, GR node, IDE, AppEngine host

Minimum 2 2 GB 100 GB 1024 x 768 100 Mbps

Medium Application Minimum 4 8 GB 200 GB 1024 x 768 1 Gbps

Minimum 8 16 GB 500 GB 1024 x 768 1 Gbps

Thin Client Node

WindowViewer, Minimum 2 1 GB 100 GB 1024 x 768 100 Mbps

Thin Client-Server Node

Basic RDS - Minimum 4 8 GB 200 GB 1024 x 768 1 Gbps

All products on a single Minimum 4 8 GB 200 GB 1280 x 1024 100 Mbps

Supported and Recommended Node Hardware Types

Product Server Thin Client- Client Node Thin Client All-In-One

Version 2017 Update 3 SP1 11

Product Server Thin Client- Client Node Thin Client All-In-One

Galaxy Repository Preferred Supported Supported No Supported

Application Engine Preferred Supported Supported No Supported

WindowViewer / InTouch ViewApp (runtime Supported Supported Preferred ITAA/RDP Supported

WindowViewer / InTouch ViewApp (runtime Supported Supported Preferred ITAA/RDP Supported

InTouch Access Anywhere Server Supported Preferred No No Supported

Historian Server Preferred Supported Supported No Supported

Historian InSight Client Browser Browser Browser Browser Browser

Historian Client (Active Factory) Supported Supported Preferred RDP Supported

OI Gatew ay Preferred Supported Supported No Supported

AVEVA Enterpris e License Server Preferred Supported Supported No Supported

AVEVA Enterpris e License Manager Preferred Supported Supported No Supported

Required Installation Order of Additional Products