PI AF 2010 R2 Installation and Maintenance Guide

PI AF 2010 R2 Installation and Maintenance Guide

OSIsoft, LLC 777 Davis St., Suite 250 San Leandro, CA 94577 USA Tel: (01) 510-297-5800 Fax: (01) 510-357-8136 Web: http://www.osisoft.com OSIsoft Australia • Perth, Australia OSIsoft Europe GmbH • Frankfurt, Germany OSIsoft Asia Pte Ltd. • Singapore OSIsoft Canada ULC • Montreal & Calgary, Canada OSIsoft, LLC Representative Office • Shanghai, People’s Republic of China OSIsoft Japan KK • Tokyo, Japan OSIsoft Mexico S. De R.L. De C.V. • Mexico City, Mexico OSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil

PI AF 2010 R2 Installation and Maintenance Guide Copyright: © 2004-2011 OSIsoft, LLC. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC. OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, PI Asset Framework (PI AF), IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Data Services, PI Manual Logger, PI ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners. U.S. GOVERNMENT RIGHTS Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC. Version: 2.3 Published: 21 December 2010

PI AF 2010 R2 Installation and Maintenance Guide iii

Table of Contents

Chapter 1 AF Installation .............................................................................................................. 5

Planning for an AF Installation ........................................................................................... 5 Installation / Uninstallation Guidelines ............................................................................. 11 Overview of AF Server Security ....................................................................................... 13 Installing AF Application Service and AF SQL Database to a Single Computer ............. 15 Installing AF Application Service and AF SQL Database to Separate Computers .......... 16 Installing the AF Server and SQL Database on a Microsoft Cluster Server .................... 16 Installing the AF SQL Database to a Mirrored SQL Server ............................................. 19 Manually Creating / Updating the AF SQL Database ...................................................... 22 Upgrading an AF Collective (HA) installation ................................................................... 25 Installing the AF Server on a Domain Controller .............................................................. 27 Installing AF Server if SQL Server has been Uninstalled / Reinstalled ........................... 28 Silent Installations ............................................................................................................ 29 Configuring Dr. Watson for Windows ............................................................................... 34

Chapter 2 AF System Configuration/Maintenance ................................................................... 37

Adding a Domain User to the AFServers Local User Group............................................ 37 Creating and Configuring the AFServers Domain User Group ........................................ 37 Manually Separating the AF Server and AF SQL Database ............................................ 38 AF Security through a Firewall ......................................................................................... 38 Configuring SQL Server ................................................................................................... 47 Using SQL Server Security .............................................................................................. 49 Modifying the AF Server’s Connect String ....................................................................... 53 Changing the AF Server’s Service Account ..................................................................... 54 Working with Untrusted Domains ..................................................................................... 58 Backing Up AF Databases ............................................................................................... 60 AF Table Security Considerations for External Tables .................................................... 61 Troubleshooting Connection Problems ............................................................................ 63 Monitoring AF Server ....................................................................................................... 65

Chapter 3 Working with AF Collectives..................................................................................... 67

AF Collectives Functional Overview ................................................................................. 67 Working with AF Collectives Through the PI System Explorer ........................................ 71 Configuring Security on the Replication Data Folder ....................................................... 84 Troubleshooting AF Collective Issues .............................................................................. 84

Table of Contents

iv

Appendix A Technical Support and Resources ....................................................................... 87

Index .............................................................................................................................................. 91

PI AF 2010 R2 Installation and Maintenance Guide 5

The default AF Server installation includes both the AF Application Service and the AF SQL Database on a single system, and uses Integrated Security. However, AF 2.2 supports a number of different installation configurations, including installing the AF Application Service and AF SQL Database to different computers, installing the AF SQL Database to a Microsoft SQL Server Cluster or Mirrored SQL Server. This section provides information on some of the more common installation approaches.

Planning for an AF Installation

Before you install AF, you should review the information in the following tables. This information will assist you with determining if you have the appropriate hardware, as well as deciding how best to configure your AF installation.

SQL Server Requirements

General Details

Application Name AF

AF Version 2010

Supported SQL Server Editions

Express Standard Enterprise Datacenter

Supported SQL Server versions

SQL Server 2005 32 bit x86 SQL Server 2005 64 bit x64 SQL Server 2008 32 bit x86 SQL Server 2008 64 bit x64 There is no support for the Itanium CPU. The 32 bit AF Server works with 32 bit or 64 bit SQL Server. The 64 bit AF Server works with 32 bit or 64 bit SQL Server

Required SQL Server components

Database engine, Agent (backup and replication) Reporting Services, Analysis Services, Integration Services, Notification Services, and so forth are not used by AF.

Hardware Requirements

Question Answer Explanation

Can the AF Application Service run on the database server system?

Yes

Can the AF Application Service run on a different system from the database server?

Yes

Chapter 1

AF Installation

AF Installation

6


Can the AF Application Service run on a system in a domain that is not trusted by the domain of the database server system?

Yes Configure the AF Application Service to use a SQL Server Login, instead of Windows Authentication when connecting to the SQL Server.

Can the database server use the default instance?

yes Modify the AF Application Service connection string to use the default instance or an appropriate alias.

Can the database server use a named instance?

Yes Modify the AF Application Service connection string to use the named instance or an appropriate alias.

If the AF Application Service is not installed on the database server system, what software, other than the SQL Server components gets installed on the database server system?

None

Will AF operate correctly when the database is installed on a shared SQL Server instance?

Yes

How many SQL Server databases does the application require?

1 or 2 The installation program creates a single SQL Server database named 'PIFD'. AF HA creates a second user database and PIFD_Distribution on the primary for SQL Server replication.

Is any specific collation required? Yes, case insensitive.

Although the installation procedure does not specify any particular collation, SQL_Latin1_General_CP1_CI_AS has had the most testing.

Does AF expect SQL Server to listen on a specific port?

No

Does the database run in MULTI_USER mode?

Yes

Are any additional SQL Server features required?

Yes SQL Agent is required for automated backup or if AF HA is used. AF HA requires the replication feature of SQL Server.

Is IIS required on the database server system?

No

Is .NET Framework required on the database server system?

Yes Unless the DBA manually installs the AF database objects, the installation program requires .NET framework version 4.0. However, this can be removed after the installation.

Is MS-DTC required? No

Is it necessary to enable remote database connections?

Depends on installation.

Yes, if the AF Application Service is not installed on the database server system.

How much disk space is required? Varies. Typical use is 1GB per 100,000 elements.




How do I size hardware for the AF SQL Server database?

Varies with application size and workload.

RAM: Reserve at least 1 GB Memory for SQL Server, up to 50K elements, 4GB up to 200K elements, 8 GB up to 2MM elements, 16 GB up to 20 MM elements. CPU: More CPUs is helpful when there are more concurrent users.

Installation - General Guidelines


Does the AF installation install SQL Server?

No

What Windows privileges are required on the database server for the database installation program?

Optionally, None. The installation of the SQL scripts, as well as verification of the SQL connection, can be optionally deselected.

Is it possible for the DBA to manually install the SQL objects without help from the installation program?

Yes

Are SQL Server scripts available for review by the DBA prior to running?

Yes The installation kit installs the SQL scripts to the PIPC\AF\SQL directory and can optionally be instructed not to execute them as part of the installation. These scripts can be run manually after the installation is complete. Alternately, install to a test system or virtual server image. Capture the SQL scripts or back up or detach the PIFD database and restore it on the production database server.

What SQL Server privileges are required on the database server for the database installation program?

The SysAdmin privilege is required if opting for the installation program to create the database. If opting for manual installation, no privileges are necessary.

Manual installation is available. See Above.

In a database-only installation, what configuration changes are made to the Windows operating system?

None. No files are installed on the database server, other than database files. No registry keys are modified.

Are any objects created in the master database?

No

Are any objects created in the msdb database?

No

Are any objects created in the model database?

No

AF Installation

8


Can the DBA control where the database data and log files are created?

Yes Prior to running the installation program, set the paths in the 'database settings' for the SQL Server instance. If manually installing, modify schema1.sql to explicitly set the paths.

Can the DBA create the database manually?

Yes Yes, "CREATE DATABASE PIFD;" The DBA can specify any paths and database options. Then, either run the installation program or run the SQL Server scripts manually.

Does AF alter instance-wide settings? Yes The PI SQL for AF installation kit enables the SQL Server CLR option. This is a SQL Server instance-wide configuration change. It is important for database administrators to understand that this configuration change affects all SQL Server user databases.

Installation - Files Installed/Registry Settings

Question Answer

What software is installed and what registry entries are affected if only the AF Server is selected for installation?

Files installed: In folder Program Files\PIPC\AF: PI.ico In folder Program Files\PIPC\AF: AFServer.common.dll AFService.exe AFService.exe.config AFService.exe.config.previous (created during an upgrade) Registry Keys HKLM\Software\PISystem\AF Server\Service AppsService <ProductVersion> HKLM\System\CurrentControlSet\Services\Eventlog\AF\AF <Values and data needed to create an AF event log> HKLM\Software\PISystem\AF Server\InstallData FD_AppsUser <User-specified value> FD_RemoteApps <User-specified value—set only if a remote application server is specified so not set in the specified scenario> FDSQLDBNAME <User-specified SQL Database name – contains PIFD database name in the specified scenario> FD_SQLSERVER <User-specified SQL Server name – contains the name of a REMOTE SQL Server in the specified scenario> Service AF Application Service created and started as part of the installation.

Authentication


Does AF support Windows Authentication? Yes




Does AF support SQL Server authentication?

Yes

Privileges


Does AF require the SysAdmin role? No

Does AF require login through the "sa" account?

No

Does AF require db_owner role? No

How many logins are required? 1 or 2. Low privileged login for account that runs the AF server needs db_afserver role. Should not be granted higher privilege. Never allow the AF Server to connect to SQL Server with SysAdmin privileges. For AF HA, the SQL Server replication is used and the "PIAdmin" user requires the SysAdmin privilege during setup or during changes to the SQL Server replication.

What roles / permissions does the AF Server need during runtime?

Account that runs the AF Server 2.x service must be a member of db_AFServer application role.

Does AF use extended stored procedures, such as XP_cmdshell?

No OSIsoft recommends that The DBA disable XP_cmdshell.

Does AF use .NET CLR embedded in SQL Server?

Yes An assembly called OSIsoft.Authorization, which supports PI SQL for AF Server, is installed on the SQL Server and requires CLR to be enabled. This component is responsible for authorization validation and reduces query results by rows that are not visible to the calling user, and thus reduces the amount of data transferred between the backend and AF Server.

User Management


Do end users connect to SQL Server? No OSIsoft recommends that end users not be granted privileges on the SQL Server instance

Must end users be granted access to SQL Server objects?

No

AF Installation

10


Does the AF Server control user access to data stored in the SQL Server database?

Yes Users do not connect to the SQL Server database. The AF Server uses Windows authentication to identify users and performs AccessCheck on Windows Security Descriptors stored in the SQL Server tables to control user access to application data.

Does each user require a login to SQL Server?

No Users do not connect to SQL Server.

Does the DBA have to manage user permissions to SQL Server objects?

No Users do not connect to SQL Server.

Does the remote application require any Windows permissions on the SQL Server machine?

Yes Except for managing AF collectives (SQL Server replication), the AF SDK never connects to SQL Server and therefore the user does not need any permission on the SQL Server. For AF HA management, the user running the AF SDK must have the SysAdmin role on the SQL Server instance, but no Windows O/S level privileges are required.

Daily Maintenance


Standard maintenance calls for log backup, daily data backup and periodic re-index on all databases. Is there any reason why this procedure should not be followed for the AF database(s)?

No

Does AF schedule any SQL Agent jobs? Yes Releases beginning with AF 2.1 schedule a SQL Agent job to back up data and logs. SQL Server replication requires the SQL Agent on the publisher (primary) instance.

High Availability SQL Server


Is AF compatible with a clustered SQL Server deployment?

Yes Compatible with SQL Server clustering, mirroring and replication.

Is AF compatible with a mirrored SQL Server deployment?

Yes Compatible with SQL Server clustering, mirroring and replication.

Is AF compatible with SQL Server replication?

Yes Depends on SQL Server transactional replication.

What SQL Server privileges do AF admin users need?

SysAdmin privileges to configure AF collectives.

Configuring an AF collective requires SQL Server Replication and therefore requires SQL SysAdmin privilege on all SQL Server instances in the AF collective.

Installation / Uninstallation Guidelines


Installation / Uninstallation Guidelines

The "Installation / Uninstallation Guidelines" section covers the following topics:

• Order of software installation (page 11)

• AF Installation Prerequisites (page 11)

• Before You Start (page 12)

• Installing / Upgrading / Uninstalling the AF Client (page 12)

• Uninstalling AF (page 13)

Order of Software Installation

The proper order for installing or upgrading the AF Server, AF Client, and AF-dependent applications, such as PI Notifications, is as follows.

1. Install Microsoft SQL Server 2005 or greater. These SQL Server editions are supported: Express, Standard, and Enterprise.

2. Install the AF Server. The AF Server does not have to be on the same system as SQL Server. If installing SQL Server separately, install the SQL Database portion of the AF installation first and the AF Application Service second.

3. Install any PI Servers that will be using the AF Server for storing the Module Database or Notification Histories. This installation must precede the AF Client installation on PI Server computers.

4. Install the AF Client. The AF Client does not have to be on the same system as the AF Server. For PI Server computers, the PI Server installations in step 3 will have already installed the client.

5. Install any AF-dependent applications, such as PI Notifications, AF 1.x to 2.x Database Upgrade Utility, or the AF Compatibility Layer, on the same system where the AF Client is installed.

Refer to each product's user manual for detailed installation procedures.

AF Installation Prerequisites

Installation of OSIsoft products rely on the presence of operating system components such as the Microsoft .NET Framework. OSIsoft product setup kits check for needed prerequisite software during installation. If not found, the installation will stop and the user will be prompted to install prerequisites. See the Prerequisites Product Pages on the OSIsoft Tech Support Web site and download either the Full - Online or Full - Offline prerequisite kit you need: OSIsoft Technical Support Prerequisites Kits (http://techsupport.osisoft.com/Products/Prerequisite+Kits/Prerequisite+Kits+Overview.htm).

http://techsupport.osisoft.com/Products/Prerequisite+Kits/Prerequisite+Kits+Overview.htm�

AF Installation

12

Note: If AF collectives will be used and if the SQL Agent on the primary AF SQL database machine runs under a domain account, you need to configure security on the primary AF SQL database machine to allow the SQL Agent service account to have access to SQL Server's \repldata folder. For instructions, see Configuring Security on the Replication Data Folder (page 84).

Before You Start

It is recommended that you complete the following actions before you run the setup program.

• Before running any of the AF installation kits, log on to your Windows system using an account with administrator privileges.

• Close any programs, particularly OSIsoft client or OSIsoft applications, that are currently running.

• Verify that your operating system is one of the following: Windows XP (SP2 or later), Windows Server 2003 (SP1 or later), Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7. Both 32 and 64 bit versions of the applicable operating systems are supported.

• Installation of an OSIsoft product relies on the presence of operating system components such as the Microsoft .NET Framework. OSIsoft product setup kits check for needed prerequisite software during installation. If not found, the installation stops and prompts the user to install prerequisites. To determine which MS Operating System prerequisites you need, see the OSIsoft Technical Support Prerequisites Kits product pages at this web site: OSIsoft Technical Support Prerequisites Kits (http://techsupport.osisoft.com/Products/Prerequisite+Kits/Prerequisite+Kits+Overview.htm).

• The AF Client set-up program checks for the presence of the PI SDK and installs or upgrades it as necessary.

Installing / Upgrading / Uninstalling the AF Client

AF Client consists of the AF SDK, PI System Explorer, and user documentation. If you are installing AF Client on the same machine as AF Server, OSIsoft recommends installing AF Server first.

To install AF Client:

1. Run the OSIsoft prerequisite kit (page 11).

The prerequisite kit installs specific versions of certain Microsoft operating system components that the AF Client installation program requires, such as .NET Framework and runtime libraries.

2. Check that you are logged in with administrative rights.

3. Run the AF Client set-up executable file. The set-up program:

ο Creates the necessary directories on your hard disk, and copies the files into the appropriate directories.



Overview of AF Server Security


ο Installs AF Client in the AF folder of the PIPC directory. ο Sets up the program folder and icons. ο Modifies the system registry.

To uninstall AF Client, use the standard Windows utility in the Control Panel for adding/removing programs.

Uninstalling AF

AF Client, Server, Compatibility Layer and Upgrade Utility can be removed from your system by selecting them for removal in the Add/Remove Programs utility in Control Panel for Windows XP and 2003 Server, or the Programs and Features Control Panel for Windows Vista, Windows 7, and 2008 Server. You must have administrator privileges on your machine to successfully uninstall AF. Uninstalling AF Server will not remove the SQL Server PIFD Database or any existing backup files. The PI SQL for AF Server should also be uninstalled when uninstalling the AF Server. If the same version or later of AF Server is later reinstalled, the existing PIFD Database will be used and upgraded as necessary.

For downgrading to previous versions of AF, after uninstalling, take the following steps:

1. For the AF Client, delete the afsdk.config file located in the Application Data directory (varies by operating system version).

2. For the AF Server, either restore the SQL Database backup of the PIFD database, or delete the PIFD database entirely. The afservice.exe.config file, located in the ..\pipc\af directory, should either be removed or restored to its previous version (afservice.exe.config.previous).

Overview of AF Server Security

The AF Server is installed assuming integrated security will be used. During the AF Server installation, the PI AF Server 2.x service is created on the AF Server system, and is configured to run under the "NT AUTHORITY\NetworkService" user account.

During the AF SQL Database installation, a local user group, AFServers, is created on the AF SQL Database machine. When the AF SQL Database is installed without the AF Server, the installation application prompts for the domain and machine name of the AF Server. The AF Server's machine account is then added to the local AFServers group on the AF SQL Database machine. When the AF SQL Database is installed along with the AF Server, then the local Network Service account is added to the local AF Servers group.

Additionally, a SQL Server Login is created which is mapped to the AFServers local user group. The SQL Server Login is given the necessary access required for the PI AF Server 2.x Service.

This setup provides the PI AF Server 2.x service on the AF Server the necessary privileges to interact with the AF SQL Database.

PI System Explorer and other AF SDK clients communicate with the AF Server using Windows authentication. Except for configuration of an AF collective, the AF SDK never

AF Installation

14

connects directly to the AF SQL Server. When you attempt to connect to an AF Server through PI System Explorer, your login credentials are used. If you have permission to access the AF Server, the connection is made. If you do not have the appropriate rights (for example, if you are logged in as a local user, not a domain user, or the client machine is in a domain other than that of the AF Server), a login dialog box appears where you can enter credentials.

If you execute an AF Client directly on the AF Server computer with a UAC (user account control) enabled operating system, using a local administrative account will not elevate the account, and you will be prompted to restart with elevated permissions. To avoid this prompt, choose one of the options below:

• Run PI System Explorer as an Administrator. On the Start menu, right-click PI System Explorer (or other AF SDK Client), and select the Run as Administrator option. There is no need for any configuration.

• Set PI System Explorer always to run as an Administrator. On the Start menu, right-click PI System Explorer (or other AF SDK Client) and select Properties. On the Compatibility tab, select the Run this program as an administrator check box.

• Modify the AF Security settings so that the user or a group containing the user (other than local Administrators), has appropriate privileges.

If your AF Server and AF SQL Database are located on different computers, see section Installing AF Application Service and AF SQL Database to Separate Computers (page 16) for configuration information.

If your AF SQL Database computer, AF Server computer, and/or the AF Client computer are not all located in the same domain, see section Working with Untrusted Domains (page 58) for configuration information.

SQL Server Authentication Modes

Microsoft SQL Server supports two authentication modes: 1) Windows Authentication, also referred to as Integrated security; and 2) SQL Server and Windows Authentication, also referred to as mixed mode security. When using integrated security, Windows will use the identity of the AF Server process to authenticate the connection to SQL Server. SQL Server Security indicates that the SQL Server account and password specified in the AF Server’s configured connection string is used to authenticate connections to SQL Server. If SQL Server security is required, then the SQL Server instance must be configured to use Mixed mode authentication; this will require a restart of the SQL Server instance. When installing or upgrading the AF SQL database, if the AF SQL Script Execution feature is selected, then the installation will require a sysadmin connection to the SQL Server through Windows Authentication. If this is not desired or possible, see the instructions for Manually Creating the AF SQL Database (page 22).

Security Best Practices

• Integrated security is recommended as it is more secure than SQL Server authentication.

• The LocalSystem account is more privileged than local Administrator account. It is strongly recommended that the PI AF Server 2.x service does NOT run under the LocalSystem account.

Installing AF Application Service and AF SQL Database to a Single Computer


• It is suggested that the AF Server 2.x service be configured to run under a domain account, as this is a more secure approach than running under the NetworkService account. (See section Changing the AF Server's Service Account (page 54) for additional information.).

• If you choose to keep the PI AF Server 2.x service running under the NetworkService account, it is important to understand that any process running under the NetworkService account on the AF Server system will have the same privileges to the PIFD database on the AF SQL Database server as the PI AF Server 2.x service.

• When your AF Server and AF SQL Database computers are located in different domains, and there is no trust defined between those domains, you will need to use SQL Server authentication to allow the two to communicate.

• If you have multiple AF Servers running in a web farm manner, and you are running the PI AF Server 2.x service on any of these computers under a domain account, then all the PI AF Server 2.x services need to run under the same domain account. The account does not need to be specified in the AF Database Properties (through the PI System Explorer) for the PI System, unless you are specifically requiring a UPN connection to the server. If the AF Servers are running under the NetworkService account, this is not necessary.

Installing AF Application Service and AF SQL Database to a Single Computer

Run the AF Server installation kit. The WinZip Self-Extractor window appears.

1. Accept the default Unzip to folder path or browse to and select a different path.

2. Click Unzip to continue with the installation.

3. When the installation files have been extracted, click OK. The Welcome to the AF Server Setup dialog box appears, with an indication of the modules that must be installed, including a Status column indicating if the modules have been installed or not.

4. Click OK to continue with the installation. The Welcome to the AF Server Installation dialog box appears.

5. Click Next to continue with the installation. The User Information dialog box appears.

6. Accept the default Full Name and Organization values, or change these values to meet your needs. Then click Next to continue with the installation. The Destination Folder dialog box appears.

7. Accept the default Destination Folder, or click Browse to locate and select a different folder. Then click OK to continue with the installation. The Select Features dialog box appears.

8. Accept the selected features and click Next to continue with the installation. The Local SQL Server Connection dialog box appears with the default SQL Server instance name, sqlexpress.

9. Enter the local computer name, and SQL Server instance name (if applicable), in the following format: <LocalComputerName>[\<SQLServerInstanceName>].

AF Installation

16

10. Click Next to continue with the installation. The Ready to Install the Application dialog box appears showing the features that will be installed.

11. Click Next to continue with the installation. The Updating System dialog box appears.

12. To cancel the installation, click Cancel. Depending on the state of the installation process when you cancel, the AF database might have already been created and you will need to remove the database manually. Otherwise, allow the installation to continue. The PI AF Server has been successfully installed dialog box appears when the installation is complete.

13. Click Finish to exit the installation. The Installation Complete dialog box appears, indicating the modules that were successfully installed, as well as any modules’ installation status(es) that had not changed.

14. The installation process is complete. Click Close to return to the system.

Installing AF Application Service and AF SQL Database to Separate Computers

The Select Features dialog box gives you the opportunity to select the features to install. By default, both the AF Application Service and the AF SQL Database features are selected for installation. To install the AF Application Service and the AF SQL Database on separate systems, follow the steps below.

1. If this is an upgrade, stop the PI AF Server 2.x service(s).

2. On the SQL Server, run the installation kit, cancel the AF Application Service selection, choosing only the AF SQL Database feature. If you are installing SQL Server manually, follow the steps in section Manually Creating the AF SQL Database (page 22) instead. During the installation, you will be prompted to provide the domain and name of the system where the remote application server can be found so that the proper authentication can be granted to the AF Application Server.

3. On the AF Server computer, run the installation, cancel the AF SQL Database selection, choosing only the AF Application Service feature. During the installation, you will be prompted to provide the name of a remote SQL Server.

It is preferable to install the SQL Server Database prior to the AF Server. The AF Server installation is not considered complete until both features have been installed.

Installing the AF Server and SQL Database on a Microsoft Cluster Server

The PI AF Server 2.x service and/or the AF SQL Database can be run on a Microsoft Cluster. This section describes how to install AF to a Microsoft Cluster.

Installing the AF Server and SQL Database on a Microsoft Cluster Server


Note: Prior to installing the AF Server to a Cluster, you must install and configure the Microsoft Cluster Server (required for both PI AF Server 2.x service and AF SQL Database) and SQL Server Cluster (required for the AF SQL Database only). For detailed information about using a SQL Server Cluster, refer to Microsoft documentation (http://msdn.microsoft.com/en-us/library/ms189134.aspx).

OSIsoft recommends that the PI AF Server service runs under a domain user account that belongs to an AF Servers domain group to support SQL Server Clustering. For detailed instructions about creating and configuring the Domain User Group, see Creating and Configuring the AFServers Domain User Group (page 37).

Installing the AF SQL Database on a SQL Server Cluster

On each node in the SQL Cluster, execute the following steps:

1. Run the AF Server installation kit.

2. On the Select Features dialog box, cancel the AF Application Service and the AF SQL Script Execution features.

3. Click Next. The SQL Server Connection dialog box appears.

4. Enter the SQL cluster name, and SQL instance (if applicable), in the format: <SQUElchier>[\<InstanceName>].

If you are installing the SQL Scripts manually, and cannot validate the SQL Server connection because of security issues, you can skip the validation step by clearing the Validate connection to the remote SQL Server check box. Note that the AF Server will not function until the SQL scripts are run and installed.

5. Click Next. The Remote Application Server Connection dialog box appears.

6. If the PI AF Server 2.x service is not running under a domain account, enter the domain name and machine name of the AF Server, in the format: <DomainName>\<AFApplicationServerComputerName>.

If you are running the AF Service under a domain account, you do not need to enter a value.

7. Click Next and continue through the rest of the install kit.

8. Open Computer Management and edit the AFServers local group.

9. If the AF Service is running under a domain account, add the name of the domain account under which the AF Service is running to the AFServers group. Be sure to include domain information for the system using this format: DOMAIN\DomainAccount.

On only the active node in the SQL Cluster, execute the following steps:

1. Create a SQL Server login and map it to the AFServers local user group.

2. If the PI AF Server 2.x service is not running under a domain account, create a SQL Server login and map it to the "NT AUTHORITY\NetworkService" user account. If the PI AF Server 2.x service is running under a domain account, skip this step.

http://msdn.microsoft.com/en-us/library/ms189134.aspx�

AF Installation

18

3. Open a DOS Command window.

4. In the DOS command window, navigate to the folder where the GO.bat file is located: ..\PIPC\AF\SQL

5. Use the following syntax to execute the SQL scripts found in the SQL folder GO.bat <SQL Server name> PIFD <SQL Server name> PIFD <SQL User Name> <SQL User Password>

where: <SQL Server name> is the local Microsoft SQL Server or SQL Server Express named instance that hosts the AF SQL database (PIFD). PIFD is the AF SQL Database.

The SQL Server User Name and Password are optional. If not provided, the scripts will use Windows Authentication to connect to the SQL Server database.

This action causes the scripts to be executed, which creates the PIAF database and populates most of its tables.

Leave the Command window open.

6. IF the AF Service is not running under a domain account that belongs to the AFServers domain group, skip this step. Otherwise, follow these sub-steps.

a. In a text editor, open Grantbat.sql, located in the .\PIPC\AF\SQL folder.

b. Change line: SET @AFSERVERSGROUP = @AFSERVERSGROUP + N'\AFServers'; to SET @AFSERVERSGROUP = N'Your Domain Name\AFServersGroup'; .

c. Comment out each line in the "Create Login and Grant Privileges for the Network Service Acct" section by placing "--" at the beginning of each line.

d. Save and close the Grantbat.sql file.

7. Execute the following commands at the command prompt: sqlcmd -S .\sqlexpress -d PIFD -i revokebat.sql

sqlcmd -S .\sqlexpress -d PIFD -i grantbat.sql

sqlcmd -S .\sqlexpress -d PIFD -i grants.sql

Where ".\sqlexpress" is the SQL Server 2005 instance that hosts the AF SQL Server database (PIFD).

Use osql to run these commands if the T-SQL execution command line utility, sqlcmd, is not installed on your system.

Installing the AF SQL Database to a Mirrored SQL Server


Installing the AF Application Service on a Microsoft Cluster Server


2. Follow the instructions in section Installing AF Application Service and AF SQL Database to a Single Computer (page 15) up to the point where you reach the Select Features dialog box.

3. On the Select Features dialog box, click the AF SQL Database feature and choose Entire feature will be unavailable.

4. Click Next. The SQL Server Connection page appears.

5. Enter the SQL cluster name, and SQL instance (if applicable), in the format: <SQLClusterName>[\<InstanceName>].

If you are installing the SQL scripts manually, and cannot validate the SQL Server connection because of security issues, you can skip the validation step by clearing the Validate connection to the SQL Server check box. Note that the AF Server will not function until the SQL scripts are run and installed.


7. If the AF application service needs to run under a domain account, see section Changing the AF Server’s Service Account (page 54).

8. If you will use the AF Server in an AF collective, then each machine in the Microsoft Cluster Service cluster must have the same Windows certificate that supports communication with the clustered AF application service:

a. Copy the AF Server certificate, named AFServer.pfx and located in the %PROGRAMDATA%\OSisoft\AF directory, from one machine in the cluster to the same location on other machines in the cluster.

b. Restart the AF application service (PI AF Server 2.x) so that it uses the new certificate.


The AF SQL Database can be run on a Mirrored SQL Server. A Mirrored SQL Server session can be implemented in various manners. The instructions provided here address a single approach, and assume the following:

• The Mirrored SQL Server session includes three computers: Principal server; Mirror server; and Witness server.

• Identical SQL Server Editions are installed on the Principal and Mirror SQL Server computers (SQL Server 2008 Standard Edition) using an Instance Name, while SQL Express 2008 was installed on the Witness computer.

• The SQL Server Engine services run under a domain account.

• AF Server is installed on a computer separate from those used in the Mirrored SQL Server session.

AF Installation

20

• The AF Client is installed on a separate computer that did not include the AF Server or the AF SQL Database.

For detailed information about deploying database mirroring, refer to this Microsoft documentation (http://msdn.microsoft.com/en-us/library/bb500175.aspx).

On both the Principal and Mirror server computers:


2. On the Select Features dialog box, deselect the AF Application Service feature.

3. Click Next. The Remote SQL Server Connection dialog box appears.

4. Enter the SQL Server name, and SQL instance (if applicable), in the format: <SQLServerName>[\<InstanceName>].

If you are installing the SQL Scripts manually, and cannot validate the SQL Server connection because of security issues, you can skip the validation step by clearing the Validate connection to the remote SQL Server check box. Note that the AF Server will not function until the SQL scripts are run and installed.

5. Click Next. The Remote Application Server Connection dialog box appears.

6. If the AF Service is not running under a domain account, enter the domain name and machine of the AF Application Server, in the format: <DomainName>\<AFApplicationServerComputerName>.

If you are running the PI AF Server 2.x service under a domain account, you do not need to enter a value.


8. If the PI AF Server 2.x service is running under the NT AUTHORITY\NetworkService account, skip this step. Otherwise, open Computer Management and edit the AFServers local user group and follow these sub-steps:

a. Add the domain account under which the PI AF Server 2.x service is running to the AFServers group.

b. Save the changes to the user group.

c. Close Computer Management.

9. Open Microsoft SQL Server Management Studio.

10. Right-click the PIFD database and select Properties.

11. In the Database Properties – PIFD window, select the Options page.

12. Set the Recovery model to Full.

13. Click OK to save the changes.

On the AF Server computer:


2. On the Select Features dialog box, deselect the AF SQL Database feature.

3. Click Next. The Remote SQL Server Connection dialog box appears.

http://msdn.microsoft.com/en-us/library/bb500175.aspx�



4. Enter the SQL Server name for the primary database server, and SQL instance name (if applicable), in the format: <SQLServerName>[\<InstanceName>].

If you are installing the SQL scripts manually, and cannot validate the SQL Server connection because of security issues, you can skip the validation step by clearing the Validate connection to the remote SQL Server check box. Note that the AF Server will not function until the SQL scripts are run and installed.


6. If the AF Application Service needs to run under a domain account, follow the instructions in section Changing the AF Server’s Service Account (page 54).

On the AF Client computer:

1. Install the AF Client, following the instructions in section Installing/Upgrading/Uninstalling the AF Client (page 12).

2. Start the PI System Explorer and connect to the AF Server computer installed in previous steps.

3. Close the PI System Explorer.

On the Principal server computer:

1. Make a full backup of the PIFD database.

2. Move the back-up file to the Mirror server computer.

On the Mirror server computer:

1. Using the back-up file you just created, right-click the PIFD database and select Task | Restore | Database. The Restore Database – PIFD window appears.

2. In the Source for restore area, select the From device option.

3. Click the From device button to browse to and select the back-up file. Return to the Restore Database – PIFD window.

4. Select the Restore check box for the newly added back-up file in the list of back-up sets.

5. In the Options page follow these sub-steps:

a. Select the Overwrite the existing database (WITH REPLACE) check box.

b. Select Leave the database non-operational and do not roll back uncommitted transactions. Additional transaction logs can be restored (RESTORED WITH NORECOVERY).

c. Click OK to start the restore operation.

d. When a message appears indicating the restore operation finished successfully, click OK to return to the Microsoft SQL Server Management Studio. The PIFD database is shown in the Restoring mode.

On the Principal server computer:

1. Right-click the PIFD database and select Task | Mirror. The Database Properties – PIFD window appears with the Mirroring page selected.

AF Installation

22

2. Click the Configure Security button. The Configure Database Mirroring Security Wizard appears.

3. In the Include Witness Server page, select the Yes option and click Next.

4. In the Choose Servers to Configure page, select the Witness server instance check box and click Next.

5. In the Principal Server Instance page, click Next. The Mirror Server Instance page appears.

6. In the Mirror Server Instance page, from the Mirror Server Instance list, select the server/instance of the Mirror server. The Connect to Server dialog box appears with the selected server/instance.

7. Click Connect to verify that you are able to connect to the Mirror server. This returns you to the Mirror Server Instance page.

8. Click Next. The Witness Server Instance page appears.

9. In the Witness Server Instance page, from the Witness server instance list, select the server/instance of the Witness server. The Connect to Server dialog box appears with the selected server/instance.

10. Click Connect to verify that you are able to connect to the Witness server. This returns you to the Witness Server Instance page.

11. Click Next. The Service Accounts page appears.

12. Leave the Principal, Witness, and Mirror boxes empty if all of the SQL Server Engines are running under the same domain account.

13. Click Next. The Complete Wizard page appears.

14. Click Finish. The Configuring Endpoints window appears. When the endpoint configuration is complete, the Status column displays Success.

15. Click Close. The Database Properties window appears, allowing for two options: Start Mirroring; Do Not Start Mirroring.

16. Click Start Mirroring. The Database Properties – PIFD window appears.

17. The Operating mode is set to High safety with automatic failover (synchronous).

18. Click OK to close the Database Properties – PIFD window. The Mirrored SQL Server session creation is now complete.

Manually Creating / Updating the AF SQL Database

You can choose to install the SQL Server scripts used to create or update the AF SQL Database (PIFD) without executing them. Do this during installation by deselecting the AF SQL Script Execution feature. When this feature is deselected, the SQL Server scripts are not executed as part of the installation process. Instead, the SQL Server scripts, along with the file, GO.bat, are placed in the folder: ..\PIPC\AF\SQL. This batch file contains the commands that execute the deployed SQL Server scripts manually. It is not necessary to run

Manually Creating / Updating the AF SQL Database


the installation on the SQL Server itself but the execution of the scripts must occur from an account with sysadmin privileges on the SQL Server Instance.

Completing the Prerequisite Steps

To enable proper interaction between an AF Application Service and the AF SQL Database created by the execution of the SQL scripts, take the following steps before running the SQL scripts:

1. On the system on which you installed the AF SQL Database, open Computer Management.

2. Create the AFServers local group if it does not already exist.

3. If the PI AF Server 2.x service is not running under a domain account, add the name of the system on which the PI AF Server 2.x service is running to the AFServers group. Be sure to include domain information for the system using this format: DOMAIN\ComputerName. In the example below, the domain is OSI and the machine name is RADAT.

If the PI AF Server 2.x service is running under a domain account, add the name of the domain account under which the AF Service is running to the AFServers group. Be sure to include domain information for the system using this format: DOMAIN\DomainAccount.

4. Create a SQL Server login and map it to the AFServers local user group.

AF Installation

24

Executing SQL Scripts

To manually create or update the AF SQL Database after installing the SQL scripts take the following steps:

1. If this is an upgrade, stop the PI AF Server 2.x service(s).

2. Open a DOS Command window.

3. In the DOS command window, navigate to the folder where the GO.bat is located: ..\PIPC\AF\SQL

4. Use the following syntax to execute the SQL scripts found in the SQL folder GO.bat <SQL Server name> PIFD <SQL User Name> <SQL User Password>

where:

<SQL Server name> is the local Microsoft SQL Server or SQL Server Express named instance that hosts the AF SQL database (PIFD). PIFD is the AF SQL database.

The SQL Server User Name and Password are optional. If not provided, the scripts will use Windows Authentication to connect to the SQL Server database.

This action causes the scripts to be executed, which creates the AF SQL Database and populates most of its tables.

Enabling Communication between the AF Application Service and the AF SQL Database

On the AF Application Service system, modify the AF Application Service's SQL Server connect string. Take the following steps:

1. In the Windows Explorer, navigate to the following folder: ..\PIPC\AF

2. Use a text editor, such as Notepad, to open The AF Application Service's configuration file, named AFService.exe.config.

3. Place the name of the remote SQL Server, and the Named Instance if applicable, in the connect string ‘server.' Refer to the following lines of code:

<?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=<SQLName>[\SQLInstance];database=PIFD;Application Name=AF Application Server;"/> <add key="streamedPort" value="5459"/>

Upgrading an AF Collective (HA) installation


If the SQL Server is running on a cluster, it is important to use the clustered resource IP address, instead of a computer name.

<?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=<SQLClusterName>[\SQLInstance];database=PIFD;Application Name=AF Application Server;"/> <add key="streamedPort" value="5459"/>

If the SQL Server is configured to use SQL Server mirroring, then add "Failover Partner=<SQLServerName>[\<InstanceName>]" after the "server=", as shown in the following lines of code:

<?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=<SQLName>[\SQLInstance];failover partner=<SQLName>[\SQLInstance];database=PIFD;Application Name=AF Application Server;"/> <add key="streamedPort" value="5459"/>

To enable encrypted communication, add "encrypt=Yes;" See the Microsoft SQL Native Client documentation for other options.

4. If the AF Application Service is running, stop and restart it for your changes to take effect.

Upgrading an AF Collective (HA) installation

The AF upgrade process requires that you run the upgrade’s executable file on each computer in the AF collective. You should upgrade your AF collective members in the order specified in this section. This minimizes the amount of time in which your AF users cannot write to the AF database, and yet maximize the availability of the AF data as read only to your AF users.

Start the upgrade process on the primary AF Server computer. After that, upgrade the secondary AF Server computers. On the AF SQL database computers, you can apply the AF upgrade in one of two manners:

• Allow the executable file to install and execute the SQL scripts.

• Allow the executable file to install the SQL Server scripts and then manually run the scripts after the installation is complete.

1. Notify users to stop making changes. Make sure replication is completed and all changes are fanned out to secondary servers.

AF Installation

26

Note: Do not continue until the replication process is complete. To verify this, check the Synchronization Status of each subscription (each secondary AF Server) on the primary AF SQL database computer, under Replication | Local Publications | [PIFD]: PIAF|[Secondary Database Server Name].[PIFD], right-click and select View Synchronization Status. After there are no replicated transactions available, continue with step 2.

2. Use the Collective tab of the PI Systems Properties dialog box to stop replication from the primary AF Server computer to all collective members.

3. On the primary AF Server computer, disable and shut down the PI AF Server 2.x service. It is important to note here that any updates that are in process are likely to be lost. It is recommended that you notify your users ahead of time that they should not attempt to make any changes to the AF data during the brief period of time it takes to install the AF upgrade.

4. On the primary AF SQL database computer, make a full backup of the PIFD and PIFD_Distribution databases. The PIFD_Distribution database is located in the System Databases container.

5. On the primary AF SQL database computer, modify the security on the C:\Program Files\Microsoft SQL Server\100 folder to provide write access to the account under which the SQL Agent is running. This is required by the operating system. For complete details about the reason for this requirement, refer to Microsoft’s Support site at Support.microsoft.com/kb/956032 (http://support.microsoft.com/kb/956032).

6. On each of the secondary AF SQL database computers, make a full backup of the PIFD database.

7. On the primary AF SQL database computer (or primary AF Server computer if the PI AF Server 2.x service and AF SQL Database are on the same computer), run the server upgrade executable file.

a. The upgrade process is similar to a standard installation. As you run the upgrade setup, a dialog box appears that requests you to verify you have made backups of your AF databases. You should have made the backups in previous steps of this section. After the backups are complete, select the Warning Acknowledged check box in the Remote PIFD SQL Database Warning dialog box and click Next.

b. In the Ready to Install the Application dialog box, the list of features to be installed appears. Only those features that were originally installed on this computer are installed by this upgrade. If the original AF SQL Database installation was done using the Execute SQL Scripts option, the list will indicate SQL Script Execution. Otherwise, it will indicate No SQL Script Execution, and you will need to execute the SQL scripts manually after the upgrade setup has finished. Click Install to begin the installation process.

c. When the installation is finished, continue with step 8, unless you need to execute the SQL scripts.

i. Open a DOS Command window.

ii. In the DOS command window, navigate to the folder where the GO.bat file is located: ..\PIPC\AF\SQL

http://support.microsoft.com/kb/956032�

Installing the AF Server on a Domain Controller


iii. Use the following syntax to execute the SQL Server scripts found in the SQL folder: GO.bat <SQL Server name> PIFD

Where:

<SQL Server name> is the local Microsoft SQL Server named instance that hosts the AF SQL database (PIFD). PIFD is the AF SQL database. This action causes the scripts to be executed, which updates the PIFD database.

iv. When the process is finished, close the DOS Command window.

d. The AF SQL database computer update is now complete.

8. If the primary PI AF Server Application Service and primary AF SQL database are on separate computers, run the same server upgrade executable file on the primary PI AF Server 2.x service computer.

a. Do not change the Destination Folder; the default is the same folder in which you previously installed AF.

b. In the Ready to Install the Application dialog box, the list of features to be installed appears. Only those features that were originally installed on this computer are installed by this upgrade. Click Install to begin the installation process.

c. When the installation process is finished, the PI AF Server 2.x service might have been reset to use the Network Service account and will be running. If you run this service under a domain account, you need to reassign the domain account to the service, then stop and disable the service.

9. On the primary AF Server computer, verify that the PI AF Server 2.x service is using the appropriate account, then enable and restart the service. Your AF Clients are now able to connect to the primary AF Server and have write access, assuming they had write access prior to the update.

10. On each of your secondary AF Server computers, disable and shut down the PI AF Server 2.x service.

11. Repeat steps 7, 8, and 9 for each of your secondary AF Servers. An exception is that you do not need to leave the PI AF Server 2.x service disabled unless you are doing a manual SQL installation.

12. Restart replication on the primary AF Server computer and all collective members that have been upgraded.

The AF collective upgrade process is now finished.

Installing the AF Server on a Domain Controller

This section describes how to manually modify the AF Server installation so that it runs on a Windows 2003 Server configured as a domain controller. Note that the AF installation does not support installing on a domain controller because OSIsoft does not recommend this deployment in a production environment. However, you can make manual modifications to allow running on a domain controller for the purposes of testing and demonstration.

AF Installation

28

Note: By default, only administrators on the AF Server have write permission to AF Databases. Those with read-only permission have fewer options displayed in the right-mouse menus. To enable other users to write to AF Databases while connected as administrator, set the system level security for groups or individuals.

Installation


2. If you are installing the AF Server on a Domain Controller, you will see errors such as: "[Microsoft][ODBC SQL Server Driver][SQL Server]Windows NT user or group '[Machine Name]\AFServers' not found. Check the name again."

3. Click OK for each error message to complete the installation. Then continue to the "Post Installation" steps, below.

Post Installation

If you saw the “…Windows NT user or group '[Machine Name]\AFServers' not found. …” error message during installation, you need to take a few manual steps to enable your AF Server to connect to the SQL Server AF Database, PIFD. Follow the steps below.

1. In a text editor, open .Grantbat.sql, located in the.\PIPC\AF\SQL folder.

2. Change line: SET @AFSERVERSGROUP = @AFSERVERSGROUP + N'\AFServers'; to SET @AFSERVERSGROUP = N'Your Domain Name\AFServers';

3. Open a command window and navigate to the ..\PIPC\AF\SQL folder.

4. Execute the following commands at the command prompt: sqlcmd -S .\sqlexpress -d PIFD -i grantbat.sql sqlcmd -S .\sqlexpress -d PIFD -i grants.sql

Where ".\sqlexpress" is the SQL Server 2005 instance that hosts the AF SQL Server database (PIFD).

Use osql to run these commands if the T-SQL execution command line utility, sqlcmd, is not installed on your system.

Installing AF Server if SQL Server has been Uninstalled / Reinstalled

An error can occur during the installation of the AF Server if the SQL Server has been uninstalled and reinstalled on a computer where the PIFD SQL Server database has been created previously. The displayed error messages are:

Server: Msg 5170, Level 16, State 1, Line 1

Cannot create file 'C:\Program Files\Microsoft SQL Server\MSSQL10.KATMAI\MSSQL\DATA\PIFD.mdf' because it already exists. Change the file path or the file name, and retry the operation.

Server: Msg 1802, Level 16, State 1, Line 1

Silent Installations


CREATE DATABASE failed. Some file names listed could not be created. Check related errors.

The steps that lead to this error are the following:

1. Install AF Server including the SQL Script execution feature that creates the PIFD database.

2. Uninstall AF Server in its entirety.

3. Uninstall SQL Server 2005 or SQL Server Express 2005 or later version.

4. Install SQL Server 2005 or SQL Server Express 2005 or later version.

5. Install AF Server including the SQL Script execution feature.

The errors shown above are issued by the SQL Server when the user is attempting to create a database that already exists but is not ‘attached’ to the SQL server.

In order to correct this problem, you must either manually remove the database files found in the folder location given by the error message or manually attach the database files to the newly-installed SQL server.


The bundled AF installations extract several installation modules. The components of the installation process, their order, and the arguments used to launch them are provided in a configuration file within the bundle, setup.ini. By modifying this file, you can provide different command line arguments to different stages of the setup. This may be useful for situations where the environment is well controlled and the options are known in advance, such as an embedded installation. Also included in the bundle are two files, (one for the AF Server and one for the AF Client), named silent.ini, that contain modifications to setup.ini that are typically needed to run a silent installation. You can augment these arguments by adding any of the options described below. For PISDK installation and arguments, see the PISDK user’s manual.

Individual arguments must not contain spaces unless they are surrounded by quotes.

AF Client Set-Up Arguments The following table lists the arguments for a silent AF Client installation:

AF Client Set-Up Arguments

Argument Description

ADDLOCAL Specifies features to install, such as the PI System Explorer, debug files, documentation, described in the following table.

ALLUSERS Specifies the per-machine or per-user installation context. Use a value of 1 for silent installations.

REBOOT Restarts the computer. Use a value of Suppress for silent installations.

AF Installation

30


AF_SERVER Specifies the AF server name used to set the default PI System for the client. If a value is not defined by the user and the AF Application Service is not resident on the target installation computer, a default PI System will not be set during the installation and the user can set the default PI System manually after the installation has completed. If a value is not defined by the user and the AF Application Service is resident on the target installation computer, the installation system will be set as the default PI System. This argument is not used during an upgrade.

The following table lists the features specified by the ADDLOCAL argument. Feature names used with the ADDLOCAL argument are case-sensitive. ADDLOCAL values consist of a comma-separated list and cannot contain any spaces. To install all features, use ADDLOCAL=ALL.

AF Client Feature / Descriptions

Internal Name / Name Used in Command Line

User-Friendly Feature Name

Description

FDClientCommonFiles N/A This feature is not seen by the user during an interactive installation. It is installed automatically during an interactive installation. It is mandatory and must be included with any subset of features specified for installation from the command line. It installs files and registry keys that must be installed with each feature.

FD_AFSDK AF Client This feature installs AF Client Core Files: the SDK and the AF Common Controls.

FD_AFExplorer AF User Interface This feature installs the PI System Explorer, which provides a user interface for displaying the hierarchical structure of the AF Servers and other AF entities.

FDDocs Documentation This feature installs the documentation, which includes AF .CHM help files and AF .PDF documentation files.

Note: The AF User Interface and Documentation features are sub-features of the AF Client feature. This means that a command-line installation including either of these two sub-features causes the AF Client to be installed as well, even if it is not explicitly specified for installation.

For a silent AF Client installation use the syntax shown in one of the following examples. Note that the /i argument specifies an installation, and the /qn argument specifies "quiet mode" and suppresses dialog boxes and prompts.



Example 1:

For this command, the AF Server value defaults to the name of the computer upon which the installation is being installed if the AF Application Service is resident on the computer when the AF Client installation is executed:

msiexec.exe /i AFClient_<Version #>.msi REBOOT=Suppress ALLUSERS=1 /qn

Example 2:

For this command, the AF Server value is the one designated by the user:

msiexec.exe /i AFClient_<Version #>.msi REBOOT=Suppress ALLUSERS=1 AF_SERVER=<User-designated AF Server name> /qn

Example 3:

For either of the two following commands, the AF Client feature is installed as well, because one of its sub-features is being installed:

• This first command line installation installs the AF Client, Documentation, and Common files: msiexec.exe /i AFClient_<Version #>.msi REBOOT=Suppress ADDLOCAL=FDClientCommonFiles,FDDocs ALLUSERS=1 /qn

• This second command line installation installs the AF Client and Common files: msiexec.exe /i AFClient_<Version #>.msi REBOOT=Suppress ADDLOCAL=FDClientCommonFiles,FD_AFExplorer ALLUSERS=1 /qn

Example 4:

For either of the two following commands, all features are installed:

• This first command-line installation specifies all the features with the ADDLOCAL property: msiexec.exe /i AFClient_<Version #>.msi REBOOT=Suppress ADDLOCAL=ALL ALLUSERS=1 /qn

• This second command-line installation specifies all the feature by default. If the ADDLOCAL property is not defined on the command line, the default is to the value of ALL: msiexec.exe /i AFClient_<Version #>.msi REBOOT=Suppress ALLUSERS=1 /qn

AF Server Set-Up Arguments The following table lists the arguments for a silent AF Server installation:

AF Server Set-Up Arguments


ADDLOCAL Specifies features to install, such as the PI System Explorer, debug files, documentation, described in the following table.

ALLUSERS Specifies the per-machine or per-user installation context. Use a value of 1 for silent installations.

REBOOT Restarts the computer. Use a value of Suppress for silent installations.

AF Installation

32


FDSQLDBSERVER Specifies the SQL Server instance.

FDSQLDBNAME Specifies the SQL Server database.

FDSQLDBVALIDATE Specifies that the SQL Server Connection is validated if the SQL Server Script Execution feature is deselected. A value of “0” will bypass the connection validation. If not specified, then the SQL Server Connection will be validated.

FD_PISQL4AF_EXEC Specifies that the PI SQL for AF feature be executed as part of an upgrade installation from versions 2.0.x.x/2.1.x.x. Use a value of 1 during a silent installation to execute the feature. Do not set from the command line if the feature is to be omitted.

The following table lists the features specified by the ADDLOCAL argument. Feature names used with the ADDLOCAL argument are case-sensitive. ADDLOCAL values consist of a comma-separated list and cannot contain any spaces. To install all features, use ADDLOCAL=ALL.

AF Server Feature / Descriptions

Internal Feature Name / Name Used in Command Line

User-Friendly Feature Name Description

FDCommonFiles N/A This feature is not seen by the user during an interactive installation. It is installed automatically during an interactive installation. It is mandatory and must be included with any subset of features specified for installation from the command line. It installs files and registry keys that must be installed with each feature.

FD_AppsServer AF Application Service This feature installs the PI AF Server 2.x service.

FD_PIOLEDBScriptExecution (Sub-feature of the FD_SQLServer feature)

PI SQL for AF This feature installs the SQL Server scripts necessary for PIOLEDB Enterprise and client products based on PI Data Services, such as PI Web Parts. This feature requires that .NET Execution (CLR) be enabled in the SQL Server.

FD_SQLServer AF SQL Database This feature installs the AF SQL Server Scripts to the AF\SQL folder.

FD_SQLScriptExecution (Sub-feature of the FD_SQLServer feature)

AF SQL Script Execution This feature handles the execution of the AF SQL Server Scripts during the installation process. If this feature is included for installation, the SQL Server scripts are executed. If it is not included, the scripts are not executed. If you include this feature in a silent installation, you must use the FD_SQLServer feature too.



For a silent AF Server installation use the syntax shown in one of the following examples. Note that the /i argument specifies an installation, and the /qn argument specifies "quiet mode" and suppresses dialog boxes and prompts.

Example 1:

With either of these commands, all AF Server features are installed: msiexec.exe /i AFServer_<Version #>.msi REBOOT=Suppress ADDLOCAL=ALL FDSQLDBSERVER=.\sqlexpress FDSQLDBNAME=PIFD ALLUSERS=1 /qn msiexec.exe /i AFServer_<Version #>.msi REBOOT=Suppress FDSQLDBSERVER=.\sqlexpress FDSQLDBNAME=PIFD ALLUSERS=1 /qn

If the ADDLOCAL property is not defined on the command line as shown above, the default is the value of ALL.

Example 2:

For this command, only the PI AF Server 2.x service is installed: msiexec.exe /i AFServer_<Version #>.msi REBOOT=Suppress ADDLOCAL= FDCommonFiles,FD_AppsServer FDSQLDBSERVER=.\sqlexpress FDSQLDBNAME=PIFD ALLUSERS=1 /qn

Example 3:

For this command, only the AF SQL Server Scripts are installed, but they are not executed as part of the installation process:

msiexec.exe /i AFServer_<Version #>.msi REBOOT=Suppress ADDLOCAL= FDCommonFiles, FD_SQLServer FDSQLDBSERVER=.\sqlexpress FDSQLDBNAME=PIFD ALLUSERS=1 /qn

Example 4:

For this command, only the AF SQL Server Scripts are installed and they are executed as part of the installation process:

msiexec.exe /i AFServer_<Version #>.msi REBOOT=Suppress ADDLOCAL= FDCommonFiles, FD_SQLServer, FD_SQLScriptExecution FDSQLDBSERVER=.\sqlexpress FDSQLDBNAME=PIFD ALLUSERS=1 /qn

Note: If you include the FD_SQLScriptExecution feature you must also include the FD_SQLServer feature.

Example 5:

For this command, the PI SQL for AF SQL Server scripts are executed as part of the 2.0.x.x/2.1.x.x upgrade installation process:

msiexec.exe /i AFServer_<Version #>.msi REBOOT=Suppress FD_PISQL4AF_EXEC=1 ALLUSERS=1 /qn

AF Installation

34

Configuring Dr. Watson for Windows

You can configure Dr. Watson to be the default debugger and have it generate a crash file dump if your system experiences an error causing a computer crash. This file can provide useful data to the OSIsoft Help Desk when they troubleshoot the crash. Follow the steps below.

1. Set Dr. Watson as the default debugger. Open a command window and enter the command drwtsn32.exe -i at the prompt.

2. Enter the command drwtsn32.exe (without the -i parameter). The Dr. Watson for Windows dialog box appears.

3. Specify the recommended settings listed below. In the figure, these are selected.

ο Crash dump type: Full ο Dump symbol table ο Dump all thread contacts ο Append to existing log file ο No visual notification

Configuring Dr. Watson for Windows


ο No sound notification ο Create crash dump file

4. Click OK to close the dialog box.

5. To test your selections, enter pidiag -crash in the command window and examine the log files that are created.


Although the AF Server installation defaults to include both the AF Application Service and the AF SQL Database on a single system, and to use Integrated Security, you can make configuration changes after AF is installed. This section provides information on some of the more common issues regarding your AF Server configuration.

Adding a Domain User to the AFServers Local User Group

When the PI AF Server 2.x service is run under a domain account, you need to add that domain account to the AFServers local user group on the AF SQL database computer.

To add a domain user to the AFServers local user group:

1. Open Computer Management on the AF SQL database computer.

2. Open the AFServers local user group.

3. Add the domain account under which the PI AF Server 2.x service is running to the AFServers group. If the PI AF Server 2.x service is running under the NT AUTHORITY\NetworkService account, add the AF server’s system account to this group.

Note: If the PI AF Server 2.x service is running as the LocalService account, then you will likely need to use SQL Server security, instead of Integrated security.

4. Close Computer Management.

Creating and Configuring the AFServers Domain User Group

When the PI AF Server and/or the AF SQL Database are run on a Microsoft Cluster, OSIsoft recommends that the PI AF Server service is run under a Domain User account that belongs to an AFServers domain group.

Note: You must have appropriate permissions to create or configure a Domain User Group. You must be a member of the Account Operators group, Domain Admins group, or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. In addition, your computer must be running a Windows Server operating system.

To add a domain user group, follow the steps below.

Chapter 2

AF System Configuration/Maintenance


38

1. Open the Active Directory Users and Computers utility and connect to the Domain in which the PI AF Server service account exists. To do this, open a Command window, enter dsa.msc and click OK.

2. Right-click Users node in the left pane, and select New Group.

3. In the Group name box, enter AFServers.

4. Set the Group Scope to Global.

5. Set the Group Type to Security.

6. Click OK to create the Domain Group.

7. Right-click the newly created AFServers group and select Properties.

8. Select the Members tab and click Add.

9. In the Enter the object names to select box in the Select Users, Contacts, Computers, or Groups dialog box, enter AFServers (the newly created Domain Group) and click OK.

10. Click OK to finalize the Domain Group editing change.

11. Close the Active Directory Users and Computers utility.

Manually Separating the AF Server and AF SQL Database

If you need to direct your AF Server to a different AF SQL Database, follow these instructions to specify a new SQL Server instance and to enable communications between the AF Server and the new AF SQL Database.

AF Server

Edit the AFService.exe.config file in the PIPC\AF folder and replace the Server information with the name of the remote SQL server to be accessed. After you have updated the AFService.exe.config file, restart the PI AF Server 2.x service for the changes to take effect.

AF SQL Database

If the PI AF Server 2.x service is using the Network Service or Local System account, add the Domain\Machine Name for the remote AF server to the local AFServers Windows group.

If the PI AF Server 2.x service has been modified to use any other account, add the account under which it is running to the local AFServers Windows group.

AF Security through a Firewall

From a network topology point of view, many customers are required to isolate the operation part of their network (the Process Control Network – PCN) from their global network (Local Area Network – LAN). Most of these customers also configure a buffer zone (the Demarcation Zone – DMZ) to install servers and software that needs to transfer data between the PCN and the LAN. The DMZ is usually isolated between firewalls.



From a server point of view, the three server components being part of the PI Platform are: the PI server (a single server or a collective of servers), the AF server and a Microsoft SQL 2005/2008 server that hosts the AF Database. While these components could be installed on a single server, we will consider here that each component is installed on a separate server because this brings up more complexity in terms of connectivity and security configuration between the different parties. In addition to this being a more interesting topology to discuss, it also distributes the processor load across several computers, which in turn increases performance of the system.

The three scenarios described in section Examples of Firewall Usage (page 39) show example topologies that illustrate possible locations for a firewall.

Examples of Firewall Usage

Scenario One

In this example, all the servers are installed in the DMZ. This simplifies the security settings between the servers because they all reside within the firewalls.

Scenario Two


40

In this scenario, only the PI server resides in the DMZ. The AF Server is connected to LAN. This is likely to happen when customers want to access data from foreign databases or synchronize AF assets with an ERP or maintenance system.

Scenario Three

In this scenario, only the SQL server does not reside in the DMZ. This may happen when customers want to use an existing SQL server to host the AF Database.



Firewalls and Network Connection Used by AF

Several network connections exist in the over-all system that include PI and AF. The figure below shows these types of connections:

• A The connections between the AF Server and any AF SDK based client, including the PI System Explorer. This connection moves structure information such as elements and models between the AF SDK and the AF Server.

• B The connection between the AF Server and Active Directory. This connection reads a list of Active Directory users, which are in turn exposed through AF as contacts.

• C The connection between AF Server and MS SQL Server 2005. This connection reads and writes structure information, such as elements and models, to a SQL database.

• D Connection between the AF client and one or more PI Servers. This connection reads and writes PI real time data and populates attribute values within the AF SDK.


42

The details of these connections and their requirements when a firewall exists are detailed in these sections.

• Firewall between AF Server and AF Client (page 42)

• Firewall between AF Server and Domain Controller (page 43)

• Firewall between AF Server and MS SQL Server (page 44)

• Firewall between AF Client and PI Server (page 46)

Firewall between AF Server and AF Client All connectivity between an AF client and the AF Server occurs through the AF SDK. For HA AF collective management, the AF SDK connects to all the SQL Servers in an AF collective. Therefore, the appropriate port must be open. The AF Server connection must use the IP address or DNS name of the AF Server, not the machine name. This is especially true when the AF Server is running on a cluster or web farm.

AF SDK communicates with the AF Server through TCP port 5457 and TCP port 5459 by default. Port 5457 is the primary port that the AF SDK uses to communicate with the AF Server from the client. Port 5459 is used by some client products, such as PI OLEDB Enterprise and PI WebParts to communicate to the AF Server. The client initiates the connection to port 5457 and 5459, so these ports must be open on the firewall to allow incoming TCP connections.

Depending on how connections are defined, the AF Server may perform a reverse name lookup of the connecting client IP address as part of the authentication process. The method chosen for name resolution may require that the AF Server be able to open outbound connections on some ports:



• Resolution by way of entries in the HOSTS file (no port requirement, but clients must have fixed IP addresses).

• Resolution by way of DNS (usually port 53).

• Resolution by way of NETBIOS name services (port 137).

Firewall between AF Server and Domain Controller The AF Server communicates with Active Directory for two purposes: to get a list of Windows domain users for use as AF Contacts, and to do user authentication and access control. Access to Active Directory for building the AF contact list can be configured to run under different security schemes. You can choose from these options during configuration:

• Select the AF Server account, the account under which the AF Server runs. The AF Server is installed using the account “Network Service” by default. If your Active Directory security is configured in a way that “Network Service” can connect, this is the simplest option.

• Specify any other account as your application requires. If your Active Directory configuration does not allow “Network Service,” then this option allows you to specify a single user who can connect to Active Directory and return the list of users. This option returns the same list of users for anyone who connects through the AF SDK.

• Impersonate a client, the account of the user who is accessing the SDK. If your Active Directory configuration does not allow “Network Service,” then this option allows you to connect to Active Directory and return the list of users. This option returns the list of users for which the users connecting to the AF SDK is allowed to view, based upon Active Directory security. This list may vary depending upon the user connecting to the AF SDK, since the security to view the users is determined by Active Directory.

In many cases, you have your Servers on one side of a firewall and the domain controllers that the users need to authenticate on the other side of the firewall. If this is the case, you need to open the following ports between your Servers and the domain controllers:

• TCP ports 137, 138, 139—These are the standard ports used for both authentication and NetBIOS services browsing for a Windows NT 4.0 domain controller and are fully supported for backward compatibility by Windows 2000 domain controllers. If you are using any version of Terminal Server or Citrix MetaFrame and the users of the server need to authenticate with a domain controller, you need to open these ports up both ways between the domain controllers and the servers.

• TCP port 88 Kerberos authentication—Windows 2000 offers an alternative and more secure method of authentication called Kerberos. If you have Windows 2000 Terminal Servers and they are authenticating with a Windows 2000 domain controller, they will use Kerberos authentication by default. If you need for users of these Windows 2000 Terminal Servers to authenticate with a Windows 2000 domain across a firewall, you will need to open up this port.

If you need to open communication between two domain controllers across a firewall for either trust relationship traffic or Active Directory traffic, refer to the Microsoft technical article Q179442. You can find additional more detailed coverage of Microsoft port usage in the following technical articles: Q150543, Q174904, and Q176466. You can look up these


44

articles at http://support.microsoft.com (http://support.microsoft.com) and enter the article "Q" number in the search window.

Firewall between AF Server and MS SQL Server During installation, the AF set-up program requires the user to select a SQL Server where the AF Database will be hosted. The PI AF Server 2.x service needs to have the appropriate credentials on the SQL Server instance to create and edit the AF Database. Depending upon the security schema configured in SQL Server (SQL, Windows authentication or both), the proper account must be used to run the AF service.

By default, for an unnamed instance, communication to the SQL Server Database engine requires port 1433 to be open; however, you can change this. For detailed information, review How to Configure a Firewall for SQL Server Access (http://msdn2.microsoft.com/en-us/library/ms175043.aspx).

The following procedure describes how to configure a Firewall for SQL Server Access.

Firewall systems prevent unauthorized access to computer resources. To access an instance of the Microsoft SQL Server Database Engine through a firewall, you must configure the firewall on the computer running SQL Server to allow access.

For general information about how SQL Server works with firewall systems, see Connecting to SQL Server over the Internet (http://msdn2.microsoft.com/en-us/library/ms175483.aspx ). There are many firewall systems available. For information specific to your system, see the firewall documentation.

Caution: Opening ports in your firewall can leave your server exposed to malicious attacks. Make sure that you understand firewall systems before you open ports. For more information, see Security Considerations for a SQL Server Installation (http://msdn2.microsoft.com/en-us/library/ms144228.aspx).

The principal steps to allow access are the following:

1. Configure the Database Engine to use a specific TCP/IP port. The default instance of the Database Engine uses port 1433, but that can be changed. Instances of SQL Server 2005 Express Edition, SQL Server Mobile, and named instances of the Database Engine use dynamic ports. To configure these instances to use a specific port, see How to: Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager) (http://msdn2.microsoft.com/en-us/library/ms177440.aspx).

2. Configure the firewall to allow access to that port for authorized users or computers.

http://support.microsoft.com/�

http://msdn2.microsoft.com/en-us/library/ms175043.aspx�







Note: The SQL Server Browser service lets users connect to instances of the Database Engine that are not listening on port 1433, without knowing the port number. To use SQL Server Browser, you must open UDP port 1434. To promote the most secure environment, leave the SQL Server Browser service stopped, and configure clients to connect using the port number. By default, Microsoft Windows XP Service Pack 2 enables the Windows Firewall, which closes port 1433 to prevent Internet computers from connecting to a default instance of SQL Server on your computer. Connections to the default instance using TCP/IP are not possible unless you reopen port 1433. The basic steps to configure the Windows XP firewall are provided in the following procedures. For more information, see the Windows documentation.

Procedures

To open a port in the Windows firewall for TCP access:

1. In Control Panel, open Network Connections, right-click the active connection, and then click Properties.

2. Click the Advanced tab, and then click Windows Firewall Settings.

3. In the Windows Firewall dialog box, click the Exceptions tab, and then click Add Port.

4. In the Add a Port dialog box, in the Name box, type SQL Server <instance name>.

5. In the Port number box, type the port number of the instance of the Database Engine, such as 1433 for the default instance.

6. Verify that TCP is selected, and then click OK.

7. To open the port to expose the SQL Server Browser service, click Add Port, type SQL Server Browser in the Name box, type 1434 in the Port Number box, select UDP, and then click OK.

Note: To allow named pipes access through the firewall, you must also enable File and Printer Sharing through the firewall.

8. Close the Windows Firewall and the Properties dialog boxes.

Note: Click Add Program in the Windows Firewall dialog box for additional options, such as granting access to specific programs and restricting access to certain IP addresses or network subnets. For more information, see the Windows documentation.

As an alternative to configuring SQL Server to listen on a fixed port and opening the port, you can list the SQL Server executable file (Sqlservr.exe) as an exception to the blocked programs. Use this method when you want to continue to use dynamic ports. Only one instance of SQL Server can be accessed in this way.


46

To access a program through the Windows firewall:

1. In the Windows Firewall dialog box, on the Exceptions tab, click Add Program.

2. Click Browse, and navigate to the instance of SQL Server that you want to access through the firewall, and then click Open. By default SQL Server is in this folder: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\Sqlservr.exe.

3. Click OK twice to close the Windows Firewall program.

For a brief tutorial about how to configure a static port, open the firewall, and connect to the Database Engine by using SQL Server Management Studio, see Getting Started with the Database Engine (http://msdn2.microsoft.com/en-us/library/ms345318.aspx).

Firewall between AF Client and PI Server AF clients need to connect to the AF Server to access the AF database. They may also need to connect directly to PI if AF elements have been configured with PI Point Data Reference. The connection to PI is established directly from the AF client. No direct connection or authentication is needed against the SQL server.

The AF Client accesses the PI Server through PI SDK. By default, communication to the PI Server requires port 5450 to be open; however, you can change this. For detailed information, review "Which Ports need to remain open on a firewall for PI3? (http://techsupport.osisoft.com/Support+Solution/7/7A928A04585C47D6A3562B7E8F630FA5.htm)" from techsupport.osisoft.com.

Connectivity to PI is achieved through TCP/IP port 5450 by default. You can verify this with a client application such as the AF Server, by pinging the PI Server by name. Almost all the latest versions of the client tools use the PI SDK to connect to PI.

Port summary

The following ports may need to be open on a firewall to allow access to PI or other associated services:

• 44 WINS - Windows name resolution.

• 53 DNS - Name resolution.

• 88 Kerberos - Windows 2000, XP authentication.

• 123 NTP Network - Time protocol, for clock synchronization.

• 135 DCOM port mapper - Windows authentication, DCOM applications including OPC, SMT 3. This port is high risk and is usually blocked.

• 137 NETBIOS Name Service - NetBIOS name resolution.

• 138 NETBIOS Datagram Service.

• 139 NETBIOS Session Service.

Note: Ports 137:139 are considered high-risk and are usually blocked.


http://techsupport.osisoft.com/Support+Solution/7/7A928A04585C47D6A3562B7E8F630FA5.htm�

http://techsupport.osisoft.com/Support+Solution/7/7A928A04585C47D6A3562B7E8F630FA5.htm�

Configuring SQL Server


• 389 LDAP.

• 445 SMB

• 636 LDAP SSL

• 1433, 1434. See: MS SQL Server (http://technet.microsoft.com/en-us/library/ms175483.aspx) and Configuring the Windows Firewall to Allow SQL Server Access (http://msdn.microsoft.com/en-us/library/cc646023.aspx).

• 3268 LDAP GC

• 3268 LDAP GC SSL

• 3389 Windows Remote desktop - Remote desktop for PI server administration.

• 5450 PI Network Manager.

• 5454:5455 PI Analysis Framework 1.x.

• 5456 PI ACE - Used by PI ACE 2 scheduler.

• 5457 AF Server.

• 5458 PI Notifications.

• 5459 AF Server (used by PI OLEDB Enterprise and PI WebParts)

Configuring SQL Server

The default AF Server installation includes both the PI AF Server 2.x service and AF SQL Database on the same system. The installation also assumes Integrated security is to be used. If your environment requires different systems and/or domains for the PI AF Server 2.x service and AF SQL Database, and or the use of SQL Server Security, you can find information in this section that explains how to configure your system.

Enabling SQL Server’s Remote Connections

If your PI AF Server 2.x service and AF SQL Database are installed on different systems, you need to ensure that SQL Server is able to accept Remote Connections. Check with your SQL Server Database Administrator and/or your Network Administrator to determine the network protocols to enable.

1. At the Start menu, point to Programs > Microsoft SQL Server 2005 > Configuration Tools and select SQL Server Surface Area Configuration. The SQL Server Surface Area Configuration window appears.

2. Click the Surface Area Configuration for Services and Connections link. The Surface Area Configuration for Services and Connections – localhost dialog box appears.

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


http://msdn.microsoft.com/en-us/library/cc646023.aspx�


48

3. Select Remote Connections for the SQL Server instance in which the PIFD database resides.

4. Select Local and remote connections option, then select the appropriate option for your environment:

Using TCP/IP only Using named pipes only Using both TCP/IP and named pipes

5. Click OK. A message appears indicating the change does not take effect until the Database Engine is restarted. Click OK to return to the SQL Server Surface Area Configuration window.

6. Close the SQL Server Surface Area Configuration dialog box.

7. At the Start menu, point to Programs > Microsoft SQL Server 2005 > Configuration Tools, and select SQL Server Configuration Manager. The SQL Server Configuration Manager dialog box appears.

Using SQL Server Security


8. Expand the SQL Server 2005 Network Configuration and select the Protocols for the SQL Server instance in which the PIFD database resides.

9. Right click the protocol you want to enable and select Enable. A message appears indicating the change does not take effect until the service is restarted. Repeat this for each network protocol that needs to be enabled. Click OK.

10. Select SQL Server 2005 Services in the left pane. In the right pane, right-click the SQL Server instance and select Restart. The SQL Server Service is restarted and your changes now take effect.


By default, AF uses Windows Authentication (Integrated Security) for gaining access to SQL Server from the PI AF Server 2.x service. However, you can modify AF to use SQL Server security instead. To use SQL Server security with AF, you need do the following:

• Configure SQL Server to Support Mixed Mode Authentication. See section Configuring SQL Server to Use Mixed Mode Authentication (page 49).

• Create and Configure the SQL Server User. See section Creating and Configuring SQL Server User (page 50).

• Modify the connect string on the AF Server. See section Modifying the AF Server’s Connect String (page 53).

Configuring SQL Server to Use Mixed Mode Authentication

To use mixed mode authentication, follow the steps below.

1. Open Microsoft SQL Server Management Studio and connect to the SQL Server Instance in which the PIFD database resides.

2. Right-click the SQL Server instance and select Properties. The Server Properties dialog box appears.

3. Select the Security page.


50

4. Select the SQL Server and Windows Authentication mode option.

5. Click OK to return to the Microsoft SQL Server Management Studio. If the SQL Server service has not been restarted since mixed mode authentication was selected, then mixed mode authentication will not be available until the SQL Server database engine service is restarted.

Creating and Configuring SQL Server User

When using SQL Server Security, you need to create a SQL Server Login, grant the SQL Server Login account access to the PIFD Database, and grant the SQL Server User the db_AFServer database role. Follow the steps below.

1. In the Microsoft SQL Server Management Studio, connect to the SQL Server Instance in which the PIFD database resides.

2. Under the SQL Server Instance, expand the Security folder; then expand the Logins folder.

3. Create a new Login and enter a name in the Login name box.

4. Select the SQL Server authentication option.

5. Enter the password in the Password and Confirm password boxes.

6. From the Default database list, select the PIFD database.



7. Select the User Mapping page.

8. Select the row for the PIFD Database.

9. Select the Map check box for the PIFD database.


52

10. With the database still selected, select the db_AFServer database role check box.

11. Click OK to close the Microsoft SQL Server Management.

Accessing External AF Tables

The AF Diagnostics Utility is a command line application that you can use to enable or disable features within the AF Server. There are three features that deal with security issues with external data tables used by an AF table. If you want to access external AF tables from either an AF 2.0.3.2019 or AF 2.0.4.2025 client, then you need to enable two features.

For details about using this utility, see section AF Server Configuration in the PI System Explorer documentation

Modifying the AF Server’s Connect String


Modifying the AF Server’s Connect String

The Connect String defines the location of the AF SQL Database and the security mode used to connect to the database. This is a standard ADO.NET connection string. The connect string is defined in the AFService.exe.config file. Some of the changes you may need to make to the connect string are: 1) Change security mode to SQL Server security; 2); Change SQL Server user and password and 3) Use a different AF SQL Database. Example Connect Strings are shown below.

Note: It is recommended that you limit access to the AFService.exe.config file to authorized users (including the account under which the PI AF Server 2.x Service runs). Do this either by limiting access to log on to the AF Server, or by setting a security descriptor on the AFService.exe.config file or its directory.

Example Connect Strings: Integrated Security <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=AFSQLDB\SQLEXPRESS;database=PIFD;Application Name=AF Application Server;"/>

Example Connect Strings: SQL Server Security <add key="connectString" value="Persist Security Info=False;Trusted_Connection=no;server=AFSQLDB\SQLEXPRESS;database=PIFD;Application Name=AF Application Server;uid=af_sql_user;pwd=af_sql_password;"/>

Specifying SQL Server Security Mode

If you want to use SQL Server security, you need to change the connect string to reference the correct security mode, and enter a SQL Server user and password. Follow these steps:

1. Open the AFService.exe.config file with a text editor, such as Notepad.

2. Locate the connect-string key. It has the following format: <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=.\phxtest;database=PIFD;Application Name=AF Application Server;"/>

3. Modify the connect string by replacing Integrated Security=SSPI with Trusted_Connection=no.

4. Modify the connect string by adding the User ID (uid) and the user’s Password (pwd) at the end of the connect string:

After your changes, the connect string resembles the following: <add key="connectString" value="Persist Security Info=False;Trusted_Connection=no;server=AFSQLDB\SQLEXPRESS;database=PIFD;Application Name=AF Application Server;uid=af_sql_user;pwd=af_sql_password;"/>


54

5. Save and close the file.

6. Restart the PI AF Server 2.x service for this change to take effect.

Specifying a Different Database Server

If your AF SQL Database is moved to a new server, or you need to work with a different AF SQL Database, you can specify the change within the connect string. Follow these steps:

1. On the AF Server computer, open the AFService.exe.config file with a text editor, such as Notepad.

2. Locate the connect-string key. It has the following format:

Integrated Security <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=.\phxtest;database=PIFD;Application Name=AF Application Server;"/>

SQL Server Security <add key="connectString" value="Persist Security Info=False;Trusted_Connection=no;server=.\phxtest;database=PIFD;Application Name=AF Application Server;uid=af_sql_user;pwd=af_sql_password;"/>

3. Modify the connect string, specifying the new location of the server. You can use a machine name or an IP address, and can include the SQL Server instance name.

Integrated Security <add key="connectString" value="Persist Security Info=False;Integrated Security=SSPI;server=AFSQLDB\SQLEXPRESS;database=PIFD;Application Name=AF Application Server;"/>

SQL Server Security <add key="connectString" value="Persist Security Info=False;Trusted_Connection=no;server=AFSQLDB\SQLEXPRESS;database=PIFD;Application Name=AF Application Server;uid=af_sql_user;pwd=af_sql_password;"/>

4. Save and close the file.

5. Restart the PI AF Server 2.x service for this change to take effect.

Changing the AF Server’s Service Account

Although the PI AF Server 2.x service is installed using the NetworkService account, it is recommended that this service be run under a domain account. Using Integrated Security, coupled with the service running under a domain account, provides you with the most secure method for protecting your AF Server.



Note: If you choose to run the PI AF Server 2.x service under the NetworkService account, it is important to understand that any process running under the NetworkService account on the AF Server system will have the same privileges to the PIFD database on the AF SQL Database server as the PI AF Server 2.x service. See section Overview of AF Server Security (page 13) for additional information.

It is important to note that if you change the PI AF Server 2.x service not to run under the NetworkService account, you need to remove the NetworkService account’s access to the PIFD database. See section Removing the NetworkService Account’s Access to the PIFD Database (page 56).

After you remove the NetworkService account from the PIFD database, any time you run the install kit (repair or upgrade), you may have to repeat this step.

To change the account under which the PI AF Server 2.x service runs:

1. Click Start, point to Programs > Administrative Tools, and select Services. The Services window appears.

2. Scroll to the PI AF Server 2.x service.

3. Right click the service and select Properties. The PI AF Server 2.x Properties dialog box appears. Then select the Log On tab as shown in the following figure.


56

4. With the This account option selected, change the account to a domain account, using the “domain\account” format. Or, click Browse to search for and select the domain account to use.

5. Enter the domain account’s password in the Password and Confirm password boxes.

6. Click OK. A message appears indicating the account has been granted the “Log On As A Service” right.

7. Click OK again. A message appears indicating the new logon name does not take effect until the service is restarted.

8. Click OK to return to the Services window.

9. Right-click the PI AF Server 2.x service and select Restart. A message appears indicating the service is being stopped, and then started. The service is now running under the new account.

You need to reconfigure your PI System’s properties to reference the new AF Server 2.x service account. You can do this in the PI System Explorer.

Removing the NetworkService Account’s Access to the PIFD Database

It is important to note that if you change the PI AF Server 2.x service not to run under the NetworkService account, you need to remove the NetworkService account’s access to the PIFD database. After you remove the NetworkService account from the PIFD database, any time you run the install kit (repair or upgrade), you may have to repeat this step.

1. Open Computer Management on the AF SQL Database system.

2. Open the AFServers local user group.

3. Select the NetworkService account and click Remove.

4. Close Computer Management.

5. Open the Microsoft SQL Server Management Studio, and connect to the SQL Server Instance in which the PIFD database resides.

6. Expand the PIFD database and navigate to the Schemas folder.



7. Right-click the “NT AUTHORITY\NetworkService” schema and select Delete to open the Delete Object window.

8. Click OK to remove the schema.

9. Under the SQL Server Instance, expand the Security folder; then expand the Logins folder.

10. Right-click the “NT AUTHORITY\NetworkService” login and select Properties.

11. Select the User Mapping page.

12. Select the row for the PIFD database.

13. Clear the check box under Map for the PIFD database.


58

14. Click OK. The “NT AUTHORITY\NetworkService” user in the PIFD database is removed, and the “NT AUTHORITY\NetworkService” login no longer has access to the PIFD database.

Working with Untrusted Domains

When your PI AF Server 2.x service and AF SQL Database systems are located in different domains, and there is no trust defined between those domains, you need to use SQL Server security to allow the two to communicate. See section Configuring the PI AF Server 2.x Service and AF SQL Database to Allow Communications (page 60). You also need to ensure that your system is configured as described in section AF Security through a Firewall (page 38).

If you do not have a primary domain controller, or if your AF Server and your PI System Explorer computers are not within the same domain, or if one of the computers is a member of a workgroup, Windows authentication uses the most basic of security models: the account(s) under which the client and server are running, which must be valid and have privileges on both computers.

Working with Untrusted Domains


This means that the AF Server must have a defined user account that is the same as the user account on the AF client computer on which the PI System Explorer runs. However, it may be necessary to take additional steps to ensure a successful connection.

Configuring PI System Explorer and the AF Server to Allow Communications

To ensure a successful connection between your PI System Explorer and the AF Server:

1. Make sure that the AF Server is version 2.0.4 or later. If the version is older, upgrade it first.

2. Create the same local account on both computers. Use the same password too.

3. Set the firewalls to open the incoming connections on AF Server. See KB 2820OSI8 (http://techsupport.osisoft.com/TechSupport/Templates/SupportSolution.aspx?NRNODEGUID=%7B3856FC8A-DCEA-46B5-A59B-93F007502E50%7D) for which ports need to be open.

4. On the client computer, log on using the new account, then open PI System Explorer and try to connect to the target AF Server. Display the System Properties dialog box from either of these dialog boxes in the PI System Explorer: On the Database Properties dialog box or the Select Database dialog box, click .

5. Set the System Properties using the Name and Host entries with the actual settings of your AF Server. Notice that the Account box remains empty.

6. Click OK.

7. Click to initiate a connection.

If the connection is not successful, you may see one of the following:

8. The best way to understand the root cause of the connection issue is to turn auditing on (described below), and to check the security-related events in the Windows Event Viewer.

Turn On Auditing

Open Administrative Tools in Control Panel. Click Local Security Settings>Audit Policy. Set the following parameters to "Success, Failure":

http://techsupport.osisoft.com/TechSupport/Templates/SupportSolution.aspx?NRNODEGUID=%7B3856FC8A-DCEA-46B5-A59B-93F007502E50%7D�

http://techsupport.osisoft.com/TechSupport/Templates/SupportSolution.aspx?NRNODEGUID=%7B3856FC8A-DCEA-46B5-A59B-93F007502E50%7D�


60

• Audit account logon events

• Audit logon events

• Audit object access

• Audit privilege use

The most probable cause of a connection problem is that the AF node did not authenticate the client user as a local user, but used the "Guest" account instead.

To allow the local computer to authenticate local users as themselves instead of "Guest":

1. On the AF server node, open the Local Security Policy: click Local Security Settings.

2. Set the following under Security Options:

ο Network access: Sharing and security model for local account --> Classic - local users authenticate as themselves.

3. Click OK to save your change and then close the dialog box.

Configuring the PI AF Server 2.x Service and AF SQL Database to Allow Communications

When the PI AF Server 2.x service and AF SQL Database are in different domains that are not trusted, or the AF Server and AF SQL Database are in a workgroup(s), you need to configure the two to allow for communications.

1. Configure SQL Server to allow remote connections. See section Enabling SQL Server’s Remote Connections (page 47).

2. Configure SQL Server to use "mixed mode authentication" to allow SQL Server authentication. See section Configuring SQL Server to Use Mixed Mode Authentication (page 49). If you change the authentication mode, you need to restart the SQL Server database engine service before the change takes effect.

3. Create and configure a SQL Server login in the SQL Server instance. This login will be assigned a default database of "PIFD" and assigned to the db_AFServer database role. See section Creating and Configuring SQL Server User (page 50).

4. Modify the connect string on the AF Server. This connect string is located in the AFserver.exe.config file on the AF Server in the "<pipc home>\AF" folder. Open the file with a text editor, such as Notepad. Modification of this file requires that you restart the PI AF Server 2.x service. See section "Modifying the AF Server’s Connect String (page 53)" in the installation and maintenance documentation.

5. If you are using a "named instance" of SQL Server, ensure that the SQL Server Browser service is running on the SQL Server computer.

Backing Up AF Databases

OSIsoft highly recommends that you back up your database on a regular basis. Use the SQL Server Management Studio or the sqlcmd command utility.

AF Table Security Considerations for External Tables


Consider these points as you design a back-up strategy:

• When the SQL Agent is available (all editions of SQL Server except Express), AF will automatically install and schedule a nightly SQL backup. Examples of SQL Server versions are: SQL Server 2000, SQL Server 2005, SQL Server 2008, SQL Server 2008 R2. Refer to the Maintenance.sql file located in the PIPC\AF\SQL directory.

• Frequency of backup depends on your application; nightly backups may be best. The default backup does a complete backup every night at 0315, local time. However, you can change the time and can change the frequency and whether full or differential backups are done.

• Place the back-up file on a different physical disk from where the SQL Server data is located. You may not be able to write to the root folder of C:\ Use another drive, such as a network drive, or a subfolder.

• SQL Express 2005 and SQL Express 2008 do not include a job scheduler, so you need to use a Windows utility to schedule the backup. You can use the following command to run the backup: sqlcmd -S <SQLINSTANCE> -d PIFD -Q "EXEC dbo.usp_backup @outpath = N'', @allwaysfullbackup = 1;" -E

You will need sysadmin, db_owner or db_backupoperator role. The least privilege is the best security practice.

• The Master database should also be backed up at some frequency. This database contains the meta-data for the PIFD database, for example, database properties, table definitions, and so forth. The AF Scheduled backup will back up the PIFD, MASTER, MSDB, and PIFD_DISTRIBUTION databases.

• The PI AF Server installation kit configures the PIFD database with a Simple Recovery Model by default. This means that transaction logs cannot be backed up and "point-of-failure" recovery is not possible. If the PIFD database is set to the Full Recovery Model, then the PIFD transaction logs should also be backed up. This will truncate the transaction logs so they do not grow without bounds and also allow either point-in-time or point-of-failure recovery. The AF scheduled backup will back up the transaction log if the database is configured with the Full Recovery Model. OSIsoft recommends that you change your PIFD database from the simple recovery model to the full recovery model to allow point-in-time recovery.

AF Table Security Considerations for External Tables

An AF Table can be configured to allow users to configure OLEDB or ODBC requests that are executed on the AF Server. Depending on how the table is configured, the request can occur using the identity of the AF Server, or using the impersonated identity of the client.

If the table is configured to use the AF Server identity, and non-impersonated external tables have been enable, and the AF Server account has been given administrative rights on a SQL Server, it may be possible for a user with AF Administrator privileges to create attacks on the SQL Server computer and can take full control of that system, depending on the configuration of that SQL Server.


62

Mitigating Factors

There are a number of security settings that must be changed before a user with AF Administrator privileges can execute an attack.

• By default, non-impersonated AF table configurations are disabled.

• Only users who are administrators on the AF System have rights to create non-impersonated external tables. By default, this includes only individuals who are already administrators on the AF Server computer.

• By default, the AF Server runs under the Network Service account and does not have administrative rights to the locally configured SQL Server or access to remote computer databases. Without administrator rights to the remote database, the possibility for elevation of privilege attacks is limited.

• By default, SQL Server’s installations do not enable xp_cmdshell or OLE Automation, which are some of the more potentially damaging vulnerabilities.

Security Recommendations

• Leave access from older AF 2.0 Clients disabled. The older AF Server RPC for returning external table data has insufficient information to determine if the user is configuring a table or executing a previously configured table. To disable, use the command line tool: afdiag /DT20-

• Optionally, to disable all non-impersonated request to external tables, use the command line tool: afdiag /DTImp-

• If access to external tables is not needed, it is possible to disable access to external tables altogether. Use the command line tool: afdiag /DT-

• SQL Server database engine service should run as a low-privilege account. Some versions of SQL Server default installations run the service as Local System. Network Service or Local Service is a better choice, or, alternately, a specifically created account with limited privileges.

• Do not grant the PI AF Server 2.x service SysAdmin (administrator) privilege on the AF SQL Server or any other SQL Server instance. (The AF installation configures the PI AF Server 2.x service account to run as Network Service and configures SQL Server to grant minimal privileges to this login.). Do not run the PI AF Server 2.x service under Local System, as that will typically grant it SysAdmin privilege on any local SQL Server instances. The PI AF Server 2.x service will log a warning message to the Windows AF Event log if the PI AF Server 2.x service is running under an account or with a SQL login with unnecessarily high privileges.

• Disable Xp_cmdshell and OLE Automation in SQL Server. Be aware that an attacker with SysAdmin privileges can re-enable these features.

• Make sure that the account that runs the SQL Server database engine does not have access to any Windows objects that it does not need to access (files, registry keys, other services, and so on).

Troubleshooting Connection Problems


• Disable SQL Server’s network listener and browser service if these are not needed. If the AF Server 2.x service is not installed on the SQL Server computer, then the network listener is required. If the SQL Server instance that AF is using is a 'named' instance, then, generally the SQL Browser service must be running.

• Do not grant non-admin AF users any SQL Server access privileges on an AF SQL Server database, except for AF collective administrators, who must have SysAdmin privilege for their Windows account.

• See these Microsoft SQL Server Security documents for further information: ο Microsoft Security Consideration for a SQL Server Installation

(http://technet.microsoft.com/en-us/library/ms144228.aspx) ο Microsoft SQL Server 2005 Security Best Practices

(http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/ SQL2005 SecBestPract.doc)

Troubleshooting Connection Problems

This section describes some connection errors that you may encounter, and gives some possible solutions.

Cannot Connect to SQL Database

Try the following:

• Check the AF Server’s connect string for correct server\instance and database name.

• Check SQL Server, to verify the PIFD database is not off-line.

Cannot Connect to PIFD Database


http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/%20SQL2005%20SecBestPract.doc�

http://download.microsoft.com/download/8/5/e/85eea4fa-b3bb-4426-97d0-7f7151b2011c/%20SQL2005%20SecBestPract.doc�


64

Try the following:

The account under which the PI AF Server 2.x service is running does not have permission to connect to the PIFD database. Assign this account the appropriate permission.

SQL Error 229

System.Data.SqlClient.SqlException: The EXECUTE permission was denied on the object 'usp_GetCollection', database 'PIFD', schema 'dbo'.

Database role db_afserver has not been granted permission to execute this stored procedure.

Try the following: Assign this account the appropriate permission.

SQL Error 2812

Try the following:

A stored procedure is missing from the AF SQL Database. Run the set-up kit in repair mode.

Cannot Connect to Specified SQL Server

System.Data.SqlClient.SqlException: An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server).

Try the following:

Monitoring AF Server


• Verify that the SQL Server database engine service is running.

• Verify that remote communication is enabled.

• Verify that the protocol is enabled.

Monitoring AF Server

You can monitor the overall readiness of AF Server with a performance counter, Health. In the Windows Reliability and Performance Monitor administrative tool, you can find this performance counter under PI AF Server. The performance counter can have two values:

• 0 — AF Server is not running or cannot establish a success connection with SQL Server.

• 1 — AF Server is running and communicating successfully with SQL Server.


AF supports multiple high availability options, including the use of AF collectives, Clustered SQL Servers, AF collectives combined with Clustered SQL Servers, or a Mirrored SQL Server.

This section provides setup, configuration and troubleshooting information for AF collectives.

For detailed instructions about installing AF with a SQL Cluster see Installing the AF Server and SQL Database on a Microsoft Cluster Server (page 16). For detailed instructions about installing AF with a Mirrored SQL Server see Installing the AF SQL Database to a Mirrored SQL Server (page 19).

AF Collectives Functional Overview

This section gives an introduction to how AF collectives work and how to administer an AF collective. OSIsoft highly recommends that an AF collective administrator review this section before starting to work with AF collectives.

Note: For collective administration, the AF SDK connects directly to SQL Server, bypassing the AF Server machine. Therefore, the Windows account of the user who is running the PI System Explorer must have the SQL Server “sysadmin” role on all SQL Servers involved in the AF collective.

How Does an AF Collective Operate?

An AF collective uses SQL Server replication to copy data from the primary AF SQL database computer (publisher) to each of the secondary AF SQL database computers. Each secondary server communicates to the primary server through a Windows Communication Foundation (WCF) connection and reports its status information. The server authenticates the WCF connection using a Windows certificate that the AF Server generated when it first started. SQL Server replication transmits the primary server’s certificate to each secondary server. After the secondary server receives the primary server’s certificate, it can communicate its status to the primary server.

Subsequent topics in this section give an overview of the processes that occur on each collective member when you are working with AF collectives.

Chapter 3

Working with AF Collectives


68

Note: If you use AF collectives and the SQL Agent on the primary SQL AF database computer runs under a domain account, you need to configure security on the primary AF SQL database computer to give the SQL Agent service account access to SQL Server’s \repldata folder. For instructions, see section Configuring Security on the Replication Data Folder (page 84).

Collective Initialization When you create a collective, SQL Server replication is initialized on the primary AF SQL database computer (publisher).

Note: If the SQL Agent service is not running on the primary server, all replication operations will fail.

• A distributor database, PIFD_distribution, is created. AF creates the distributor database in the same SQL Server instance as the primary PIFD database.

• A set of tables, indexes, triggers, constraints are marked for replication.

• A snapshot agent is started and makes a snapshot of the primary database is written to the \repldata folder. This process can take some time; the more data being replicated the longer the process.

• A log reader agent is started and sends any changes to the marked tables, to the distributor database.

Secondary Server is Added to Collective You can add a secondary server to a collective when the collective is first created, or after the collective has been created. When you add a secondary server (subscriber) to a collective:

• A push subscription is set up in the PIFD_distribution database.

• A push subscription agent is started, one for each secondary server added to the collective.

• The push subscription agent pushes the current snapshot to the secondary server(s) to initialize the secondary server(s). All the tables that are marked for replication are pushed to the secondary server. Any pre-existing data on the secondary server(s) is lost.

AF Data is Changed on the Primary Server • The log reader agent sends any changes from PIFD to the PIFD_distribution database.

• For each secondary server, its agent pushes changes to the SQL Server instance on the secondary server. The SQL Agent service on the primary must have the appropriate permissions to write to each secondary server’s SQL Server instance. If the secondary server is not reachable (if there is a network problem or the computer is offline), the agent retries later.

AF Collectives Functional Overview


A Secondary Server is Reinitialized by the PI System Explorer • A new snapshot is created on the primary server.

• Agent pushes the snapshot to the secondary server(s) to initialize the secondary server(s). All the tables that are marked for replication are pushed to the secondary server(s). Any pre-existing data on the secondary server(s) is lost.

Replication is Stopped on a Secondary Server There is no pause option and no resume option for replication; replication is either running or stopped.

• The subscription is dropped on both ends (primary server and secondary server).

• The push agent for the secondary server is stopped.

Replication is Stopped on the Primary Server There is no pause option and no resume option for replication; replication is either running or stopped.

• The subscription is dropped on both ends (primary server and secondary server).

• All agents are stopped.

• The PIFD_distribution database is deleted.

• All replication is halted.

A Secondary Server is Removed from a Collective • The subscription is dropped on both ends (primary server and secondary server).

• The push agent for the secondary server is stopped.

• The secondary server is removed from the collective.

The Primary Server is Removed from a Collective • The subscription is dropped on both ends (primary server and secondary server).

• All agents are stopped.

• The PIFD_distribution database is deleted.

• The collective is removed and the primary server is available as a standalone PI System.

• All replication is halted and cannot be restarted.

AF Collective Administrative Tasks

The following sections provide information about how to manage an AF collective.


70

Is a Backup of the SQL Server Data Required? OSIsoft highly recommends that you make regular backups of SQL Server data, especially on the primary server. The AF installation process creates a SQL Server back-up job that is scheduled to run by the SQL Agent. Make sure you copy these backups to media other than the media that contains the data.

What if the Primary SQL Server Machine has a Catastrophic Failure? Set up a new primary SQL Server and restore from a backup (PIFD, PIFD_DISTRIBUTION, master, msdb). If this is not possible, create a new collective.

What if a Secondary SQL Server Machine has a Catastrophic Failure? • On the primary server, stop replication to the missing secondary server.

• On the primary server, add a new secondary server and start replication to the new secondary server.

How to Upgrade AF on a Primary Server • Stop the AF Server(s) services attached to the primary server. This causes all connected

clients to fail over to a secondary server. If any mutative operations are in flight, they will likely be lost.

• Back up the AF data (PIFD, PIFD_DISTRIBUTION, master, msdb).

• Apply any Windows or SQL Server patches.

• Reboot the computer, if necessary.

• Run AF .sql scripts against the primary server. This causes any schema changes and reserved object changes to be replicated to the secondary servers.

• Upgrade the AF Server(s) attached to the primary server.

• Run a test to verify connections are correct and data is moving from primary server into secondary server(s).

How to Upgrade AF on a Secondary Server • Upgrade the primary server, and return the primary server to service. It is very important

that the primary server upgrade was successful and all schema/data was replicated to this secondary server. Look at the status to see if there are any pending replication transactions for this secondary server.

• Stop the PI AF Server 2.x service attached to the secondary server.

• Apply any Windows or SQL Server patches.


• Run AF .sql scripts against this secondary server. Since the schema changes were already replicated from the primary server, there should not be any schema changes on

Working with AF Collectives Through the PI System Explorer


the secondary server for tables that are replicated. The .sql scripts will replace all the stored procedures.

• Upgrade the AF Server(s) attached to the secondary server.

• Run a test to verify connections are correct and data is moving from primary server into secondary server.

• Repeat for each secondary server in the collective.

How to Apply a Windows Patch to a Running Collective • Apply Windows patch(es).


How to Apply a SQL Server Patch to a Running Collective • Apply SQL Server patch(es).



This section describes how administrative users interact with the PI System Explorer to create and manage AF collectives. In the future, however, you will typically use Collective Manager to do this.

Note: For details about switching between collective members within the PI System Explorer, see Connecting to a Specific Member of a Collective in the PI System Explorer documentation.

Creating a New Collective

Note these key points:

• The system acting as the primary server must be using SQL Server, not SQL Server Express. Secondary systems that you choose can use SQL Server Express, however.

• For collective administration, the AF SDK connects directly to SQL Server, bypassing the PI AF Server 2.x service computer. Therefore, the Windows account of the user who is running the PI System Explorer must have the SQL Server "sysadmin" role on all SQL Servers involved in the AF collective.

• SQL Server replication depends on the SQL Agent service. If it is not running, when a user attempts to set up an AF collective, the setup fails without warning. The only way to recover is to delete the collective, start the SQL Agent, then set up the collective.

• If AF collectives will be used and if the SQL Agent on the primary SQL AF database computer runs under a domain account, you need to configure security on the primary AF SQL database computer to allow the SQL Agent service account to have access to SQL


72

Server's \repldata folder. For instructions, see section Configuring Security on the Replication Data Folder (page 84).

To create a collective:

1. Click File>Database. The Select Database dialog box appears.

2. Click . The Systems dialog box appears.

3. Right-click and select Create Collective. Right-clicking a PI System and selecting Create Collective causes the selected PI System to default as the primary server. You can select a different primary server later in the process, if necessary. The Create New Collective - Verify Backup Completed dialog box appears.

4. After verifying that a good backup of the PI Systems that will be involved in the collective exist, select the I have verified my backups are valid check box and click Next. The Create New Collective - Select Primary dialog box appears.

5. Accept the current PI System as the Collective Primary, or select a different PI System from the Collective Primary list to use as the primary server of the new collective. The PI System name is used as the Collective Name; you can change the name after the collective has been created.

6. If there is a current connection to the selected PI System, the PI System's description appears in the Primary Description box; otherwise the box is blank. Accept the default Primary Description or enter a new description. You can change the Primary Description after the collective has been created.

7. Enter a description for the collective in the Collective Description box or leave it blank. You can change the description after the collective has been created.

8. Click Next. The Create New Collective - Select Secondary Servers dialog box appears.

9. From the Server list, select the PI System to add to the collective as a secondary server. You can change the server description, or accept the current description. If there is not a current connection to the selected PI System, the PI System's description will not be displayed. Click Add to add the PI System to the list.

Note: You can create a collective without adding a secondary server. You can add secondary servers after the collective is created.

10. Repeat the previous step for any additional PI Systems that are to be added as secondary servers in this collective.

11. Click Next. The Create New Collective – Verify Selections dialog box appears.

12. At this point, you can click Next to finish creating the collective, or examine the advanced options.

To bypass the advanced options, click Next. The collective is created and the Create New Collective – Finishing dialog box appears. The replication process begins.

To examine the advanced options, click Advanced.

a. You will be prompted to convert the system(s) to a collective if you want to continue. Click Yes to convert the system(s) to a collective and open the Advanced Collective



Options dialog box. Click No to return to the Create New Collective - Verify Selections dialog box and make any required changes.

The following figure shows an example configuration for the advanced options.

b. You can make changes to the collective’s definition at this point or leave the definition as is. For detailed information about the collective’s definition, see section Configuring the Collective Properties (page 75).

c. Click OK to start replication. The Create New Collective – Finishing dialog box appears and the replication process begins.

13. The Create New Collective – Finishing dialog box consists of three areas. For details about the collective status, see section Collective Status Details (page 75).

Note: If you click Exit prior to the secondary server's being listed in the lower area of the dialog box, replication process stops on any secondary server(s) in the collective. A message appears that indicates the replication process is not complete. You will need to start the replication process on any secondary server(s) that currently belong to the collective.


74

14. If you click Finish before the replication is complete, a message appears indicating the replication is not complete, and where to look for the current replication status.

When the replication process is complete, the status for the first row, the snapshot creation, shows Succeeded. The status for the second row, the replication process as it relates to the primary server, shows Idle. The status for the third row and on, the replication process as it relates to the secondary server(s), shows Idle.

15. Click Finish to close the Create New Collective – Finishing dialog box.



Checking the Status of a Collective

Status information is reported for AF collectives in the same way as it is for PI collectives. To see the status:


2. Click . The System Properties dialog box appears.

3. Click the Collective tab to view the collective configuration information.

For detailed information about the collective’s definition, see section Configuring the Collective Properties (page 80).

4. Select a collective member to review the member’s status in the Status area of the Collective tab.

5. Right-click a collective member and select Show Collective Status, or select a collective member and click in the Status area. The Collective Status Details dialog box appears with the last status messages for the primary and secondary servers. If there is no current activity, the Details area is empty. For details about the Collective Status Details dialog box, see section Collective Status Details (page 75).

Collective Status Details You can review the collective’s status details while the collective is being created or a secondary server is being added, or in the Collective Status Details dialog box (after the collective has been created).

The following figure shows the Create New Collective – Finishing dialog box.


76

The following figure shows the Adding Secondaries – Finishing dialog box.

The following figure shows the Collective Status Details dialog box.



In the Create New Collective – Finishing and the Adding Secondaries – Finishing dialog box, the top area provides messages indicating the overall status of the collective creation and replication process. The middle area provides an overview of the replication process. In these two dialog boxes and in the Collective Status Details dialog box, the lower area displays rows of data about the PI Systems comprising the collective. In the Collective Status Details dialog box, the top area allows you to: 1) Refresh the contents of the dialog box; 2) Choose to show only errors; and 3) Indicate the number of rows of data details to display for secondary servers.

The first two rows in the lower area of all three dialog boxes are related to the primary server. The first row shows the status of the snapshot creation process. The second row shows the status of the replication process between primary server and secondary server(s). The rows in the lower area beginning with the third row are related to the secondary server(s), showing the latest status messages relating to the replication process on the secondary server(s).

The columns in all three dialog boxes are:

• Name: The name of the collective member.

• Sync Status: The synchronization status between the server members in the collective.

• Status: The status of the replication process from the primary server to the secondary server(s).

• Comment: The current stage of the replication process.

• Commands Delivered: The number of commands being sent from the primary server to the secondary server.

• Error Code: If an error occurs, displays the associated error code.

• Error Message: If an error occurs,, displays the associated error message.

Note: If you click Exit prior to a newly added secondary server(s) being listed in the lower area of the dialog box, replication process stops on the secondary server. A message appears that indicates the replication process is not complete. You will need to start the replication process on the newly added secondary server.

Adding a Secondary Server to a Collective

You can add secondary servers to an existing collective. When a secondary server is added to a collective, a subscription is created on the secondary server, and the existing snapshot data is replicated from the primary server to the newly added secondary server.

To add a server:


2. Click . The Systems dialog box appears.

3. Click the Collective tab.

4. Right-click a server and select Add PI System to Collective. The Adding Secondaries – Select Secondary Servers dialog box appears.


78

5. From the Server list, select the PI System to add to the collective as a secondary server. You can change the server description, or accept the current description. If there is not a current connection to the selected PI System, the PI System's description will not be displayed. Click Add to add the PI System to the list.

6. Repeat the previous step for any additional PI Systems that you want to add as secondary servers in this collective.

7. Click Next. The Adding Secondaries - Verify Selections dialog box appears.

8. At this point, you can click Next to finish adding the secondary server(s) to the collective, or examine the advanced options.

To bypass the advanced options, click Next. The secondary server(s) is/are added to the collective. The Adding Secondaries – Finishing dialog box appears. The process of replicating data to the secondary server(s) begins.

To examine the advanced options, click Advanced. The following figure shows an example configuration for the advanced options.



a. You can make changes to the collective’s definition at this point or leave the definition as is. For detailed information about the collective’s definition, see section Configuring the Collective Properties (page 80).

b. Click OK to start replication. The Adding Secondaries – Finishing dialog box appears and the replication process begins.

9. The Adding Secondaries – Finishing dialog box consists of three areas. For details about the collective status, see section Collective Status Details (page 75).

Note: If you click Exit prior to the newly added secondary server(s) being listed in the lower area of the dialog box, replication process stops on these secondary server(s). A message appears that indicates the replication process is not complete. You will need to start the replication process on any secondary server(s) that currently belong to the collective.

When the replication process is complete on the secondary server(s), the Status for the third row and on, the replication process as it relates to the secondary server(s), shows Idle.


80

10. Click Finish to close the Adding Secondaries – Finishing dialog box.

Configuring the Collective Properties

You can modify many settings relating to collective members in either the Advanced Collective Options dialog box (during the collective creation process) or the Collective tab in the System Properties dialog box (after the collective has been created).

The following figure shows an example configuration for the advanced options.



Select a collective member to display the following settings:

• Name: Collective member's name. Default is the collective member's PI System name. You can change the name.

• Description: Collective member's description. Default is the collective member's PI System description. You can change the description.

• Host: The FQDN (fully qualified domain name) of the collective member. This value is read only.

• Port: The port through which the AF Server communicates. This value is read only; it is set in the PI System's configuration, prior to becoming a collective member.

• Account: The account under which the AF Service is running. This value is read only; it is set in the PI System's configuration, prior to becoming a collective member.

• Timeout: The number of seconds for an operation to finish on the AF Server. This value can be modified for each collective member.

• Priority: Indicates the priority order for which to select the collective member on the current computer. You can modify this value for each collective member.

• Role: The role within the collective of the selected collective member, primary or secondary. This value is read only; it is set when the PI System is added to the collective.

• Period: The frequency, in seconds, in which a collective member checks the status of the remaining collective members. You can modify this value for each collective member.

• Grace: The time period, in seconds, that is allowed before the communication status is set to TimedOutOnPrimary when there is no communication with the primary server. You can modify this value for each collective member.

• Server Version: Version of the AF Server installed. This value is read only.

• Database Version: Version of the AF SQL Database installed. This value is read only.


82

• Status: The status of the selected collective member, including the last time communication was verified with the primary server (not listed for the primary server), the last time the collective member was synchronized, current synchronization status, and current communication status. These values are read only.

• More: Click to display the Collective Status Details dialog box.

• Refresh: Click to refresh the details of the collective members.

Removing a Server from a Collective

You can remove a server from a collective as needed. Note that removing the primary server from the collective causes the entire collective to be deleted.

To remove a server:

1. Click File>Database to open the Select Database dialog box.

2. Click to open the System Properties dialog box.


4. Right-click the server and select Delete. The secondary server is removed from the collective and becomes available in the Systems dialog box.

For details about the events that occur when you remove a secondary server from a collective, see section A Secondary Server is Removed from a Collective (page 69). For details about the events that occur when you remove a primary server from a collective, see section The Primary Server is Removed from a Collective (page 69).

Stopping Replication on a Secondary Server

You can stop replication on a secondary server at any time. For details about the events that occur when you stop replication on a secondary server, see section Replication is Stopped on a Secondary Server (page 69).




4. Right-click the server and select Stop Replication. Replication is stopped on the secondary server. As long as the server is a member of the collective, you can start replication at a later time.



Stopping Replication on the Primary Server

You can stop replication on the primary server at any time. For details about the events that occur when you stop replication on the primary, see section Replication is Stopped on the Primary Server (page 69).




4. Right-click the server and select Stop Replication. Replication is stopped on the primary server and all secondary servers. As long as the collective still exists, you can start replication on the primary server at a later time; you will need to start replication on each secondary server, too.

Starting Replication on a Server

If you have stopped replication on a collective member, it does not restart automatically. If you want the collective member to be involved in replication, you must start the replication on that member.




4. Right-click the server and select Start Replication. If this is the primary server, you also need to start replication on each secondary server.

Reinitialize a Collective Member

You can force a new snapshot of the database on the primary server to be created and pushed out to a secondary server by reinitializing the secondary server. If you have multiple secondary servers, you must reinitialize each individually.




4. Right-click the server and select Reinitialize Replication. For details about the events that occur when you reinitialize a member, see section A Secondary Server is Reinitialized by the PI System Explorer (page 69).


84

Configuring Security on the Replication Data Folder

If you intend to use AF collectives and your SQL Agent service runs under a domain account, you need to configure security on SQL Server’s \repldata folder on the primary AF SQL database computer to allow the SQL Agent’s service account to have access.

1. On the primary AF SQL database computer, open Windows Explorer.

2. Navigate to the \repldata folder for the SQL Server instance in which the AF SQL Database is installed.

3. Right-click the \repldata folder and select Properties to open the repldata Properties dialog box.

4. Click the Security tab.

5. Click the Edit button to open the Permissions for repldata dialog box.

6. Click the Add button to open the Select Users, Computers, or Groups dialog box.

7. Ensure that the From this location: area shows the correct domain. If not, use the Location button to navigate to and select the correct domain.

8. In the Enter the object names to select area enter the name of the domain account under which the SQL Agent runs.

9. Click OK to return to the Permissions for repldata dialog box.

10. In the Permissions for [SQL Agent Account Name] area, select the Modify check box, ensuring that all but the Full control and Special permissions check boxes are selected.

11. Click OK to return to the repldata Properties dialog box.

12. Click OK to return to Windows Explorer.

13. Close Windows Explorer.

Troubleshooting AF Collective Issues

Status Details Indicates No Configured Subscriber This message indicates no secondary server has been configured for replication. If a secondary server has already been added to the collective, the error could indicate there is a communication problem between the primary AF Server and secondary AF Server, or between the secondary AF Server and the secondary AF SQL Database.

If the failure was due to a problem between the primary AF Server and secondary AF Server, review the AF event log on the secondary AF Server for possible causes of the error. Verify the user account used in the PI System Explorer has the proper access to the AF Server.

If the failure was due to a problem between the secondary AF Server and the secondary AF SQL Database, review the AF event log on the secondary AF SQL Database for possible causes of the error. Verify the user account used in the PI System Explorer has the proper access to the AF SQL Database.



Collective Creation Fails Due to Login Failure When creating a collective, the Create New Collective – Finishing dialog box displays the following message in top section: “Login failed for user ‘[DOMAIN]\[UserName]’.”

This message indicates that the logged-on user is unable to access one of the servers included in the collective. The error is most likely related to the fact that the logged-on user does not have the correct permissions on the primary AF SQL Database computer. Review the Application Event logs on the AF Server and AF SQL Database computers, beginning with the primary AF Server, to determine which computer is receiving the connection error.

See section Creating and Configuring SQL Server User in the AF Installation appendix for detailed instructions about creating a new SQL Server Login. Be sure that the login account is given “sysadmin” privileges to SQL Server on the AF SQL Database computer.

Snapshot Creation Fails Due to Access Error During creation of a collective, the Create New Collective – Finishing dialog box displays the following message in the middle section: “Current SyncStatus(Snapshot not ready).” In the SnapShot status row (the first row in the bottom section), the message displays “Access to the path ‘[..\repldata\...] is denied.”

This message indicates that the SQL Agent account does not have Write access to the \repldata folder for the SQL Server instance into which the Primary AF SQL Database was installed. See section Configuring Security on the Replication Data Folder (page 84)). After setting the proper security on the \repldata folder, exit the Create New Collective – Finishing dialog box. A message appears, indicating the primary server’s replication has not finished. Click OK and return to the Collective tab in the System Properties dialog box. Delete the collective, then recreate the collective, and the snapshot is created correctly.

Collective Can’t be Created Because SQL Server Agent is not Running You attempt to create a collective by right-clicking a PI System in the Systems dialog box, and select Create Collective: if the SQL Server Agent for the selected PI System is not running, a message appears indicating the SQL Agent is not running on the AF SQL Database computer. Click OK to return to the Systems dialog box. Start the SQL Agent on the primary server, then create the new collective.

You attempt to create a collective by right-clicking in the white area of the Systems dialog box, and an error dialog box appears, along with the Create New Collective – Finishing dialog box, indicating: "SQL Server Agent is not running." Click OK to exit the error dialog box. In the Create New Collective – Finishing dialog box the same message appears. Click Cancel to exit the dialog box. The collective was not created. Start the SQL Agent on the primary server, then create the new collective.


You can read complete information about technical support options, and access all of the following resources at the OSIsoft Technical Support Web site:

http://techsupport.osisoft.com

For information on programming and integration with OSIsoft products see the OSIsoft vCampus Web site, or the OSIsoft vCampus section at the end of this document.

Before You Call or Write for Help

When you contact OSIsoft Technical Support, please provide:

• Product name, version, and/or build numbers

• Computer platform (CPU type, operating system, and version number)

• The time that the difficulty started

• The log files at that time

Help Desk and Telephone Support

You can contact OSIsoft Technical Support 24 hours a day. Use the numbers in the table below to find the most appropriate number for your area. Dialing any of these numbers will route your call into our global support queue to be answered by engineers stationed around the world.

Office Location Access Number Local Language Options

San Leandro, CA, USA 1 510 297 5828 English

Philadelphia, PA, USA 1 215 606 0705 English

Johnson City, TN, USA 1 423 610 3800 English

Montreal, QC, Canada 1 514 493 0663 English, French

Sao Paulo, Brazil 55 11 3053 5040 English, Portuguese

Frankfurt, Germany 49 6047 989 333 English, German

Manama, Bahrain 973 1758 4429 English, Arabic

Singapore 65 6391 1811 86 021 2327 8686

English, Mandarin Mandarin

Perth, WA, Australia 61 8 9282 9220 English

Appendix A

Technical Support and Resources


88

Support may be provided in languages other than English in certain centers (listed above) based on availability of attendants. If you select a local language option, we will make best efforts to connect you with an available Technical Support Engineer (TSE) with that language skill. If no local language TSE is available to assist you, you will be routed to the first available attendant.

If all available TSEs are busy assisting other customers when you call, you will be prompted to remain on the line to wait for the next available TSE or else leave a voicemail message. If you choose to leave a message, you will not lose your place in the queue. Your voicemail will be treated as a regular phone call and will be directed to the first TSE who becomes available.

If you are calling about an ongoing case, be sure to reference your case number when you call so we can connect you to the engineer currently assigned to your case. If that engineer is not available, another engineer will attempt to assist you.

Search Support

From the OSIsoft Technical Support Web site, click Search Support.

Quickly and easily search the OSIsoft Technical Support Web site's support solutions, documentation, and support bulletins using the advanced MS SharePoint search engine.

E-Mail–Based Technical Support

[email protected]

When contacting OSIsoft Technical Support by e-mail, it is helpful to send the following information:

• Description of issue: Short description of issue, symptoms, informational or error messages, history of issue.

• Log files: See the product documentation for information on obtaining logs pertinent to the situation.

Online Technical Support

From the OSIsoft Technical Support Web site, click My Support > My Calls.

Using OSIsoft's Online Technical Support, you can:

• Enter a new call directly into OSIsoft's database (monitored 24 hours a day)

• View or edit existing OSIsoft calls that you entered

• View any of the calls entered by your organization or site, if enabled

• See your licensed software and dates of your Service Reliance Program agreements



Remote Access

From the OSIsoft Technical Support Web site, click Contact Us > Remote Support Options.

OSIsoft Support Engineers may remotely access your server in order to provide hands-on troubleshooting and assistance. See the Remote Support Options page for details on the various methods you can use.

On-Site Service

From the OSIsoft Technical Support Web site, click Contact Us > On-site Field Service Visit.

OSIsoft provides on-site service for a fee. Visit our On-site Field Service Visit page for more information.

Knowledge Center

From the OSIsoft Technical Support Web site, click Knowledge Center.

The Knowledge Center provides a searchable library of documentation and technical data, as well as a special collection of resources for system managers. For these options, click Knowledge Center on the Technical Support Web site.

• The Search Support feature allows you to search Support Solutions, Bulletins, Support Pages, Known Issues, Enhancements, and Documentation (including user manuals, release notes, and white papers).

• System Manager Resources include tools and instructions that help you manage archive sizing, backup scripts, daily health checks, daylight saving time configuration, PI Server security, PI System sizing and configuration, PI trusts for interface nodes, and more.

Upgrades

From the OSIsoft Technical Support Web site, click Contact Us > Obtaining Upgrades.

You are eligible to download or order any available version of a product for which you have an active Service Reliance Program (SRP), formerly known as Tech Support Agreement (TSA). To verify or change your SRP status, contact your Sales Representative or Technical Support (http://techsupport.osisoft.com/) for assistance.

OSIsoft Virtual Campus (vCampus)

The OSIsoft Virtual Campus (vCampus) Web site offers a community-oriented program that focuses on PI System development and integration. The Web site's annual online subscriptions provide customers with software downloads, resources that include a personal development PI System, online library, technical webinars, online training, and community-oriented features such as blogs and discussion forums.

http://techsupport.osisoft.com/�


90

OSIsoft vCampus is intended to facilitate and encourage communication around PI programming and integration between OSIsoft partners, customers and employees. See the OSIsoft vCampus Web site, http://vCampus.osisoft.com (http://vCampus.osisoft.com) or contact the OSIsoft vCampus team at [email protected] for more information.

http://vcampus.osisoft.com/�


A

AF, Port Summary • 46 AF, Security and a Firewall • 38 AF, Security Overview • 13

B

Back Up Database • 60

C

Collective, Administration • 69 Collective, Creating • 71

D

Database, Backing Up • 60 Debug with Dr. Watson • 34 Dr. Watson Configuration • 34

F

Firewall and AF Security • 38

I Installation Guidelines • 11 Installation Options for AF • 5, 15, 16, 19, 22, 27, 28 Installation, Silent • 29

P

Port Summary • 46 Ports and Firewall Security • 46

S

Security • 13, 14, 16, 27, 38, 49, 58 Silent Installation • 29 SQL Server Configuration Options • 14, 38, 47, 49,

53, 54, 63 SQL Server Security • 14, 49

U

Uninstallation Guidelines • 12, 13

Index

PI AF 2010 R2 Installation and Maintenance Guide

Documents

af installation

brazil pi af

pi asset framework pi

af sql database

pi system

mexico osisoft

pi datalink

pi analytics