PI3ReleaseNotes 3.4.380.36

PI Server 3.4.
380 – Windows Integrated Security
Release Notes
PI Server Version 3.4.380.36

2009 © OSIsoft, Inc. All rights reserved
Table of Contents
Overview ................................................................................................................... 1
Supported Operating Systems ............................................................................... 2
Hardware Virtualization Support.......................................................................... 3
Known Issues with Windows Server 2008/Vista ................................................. 3
Known Issues with Windows Server 2008 R2 Core ............................................ 4
Known Issues with Performance Counters ......................................................... 5
Choosing Between the 32-bit and 64-bit Setup Kits............................................ 6
Installation and Upgrade ......................................................................................... 6
Installation Prerequisites ..................................................................................... 6
Upgrading PI Server Collectives ......................................................................... 7
Installing and Uninstalling on Windows Server Core .......................................... 7
Silent Installation or Upgrade .............................................................................. 8
Documentation .................................................................................................... 8
Known Issues ........................................................................................................... 9
PLI # 20555OSI8 ................................................................................................. 9
PLI # 20761OSI8 ................................................................................................. 9
PLI # 20773OSI8 ...............................................................................................10
PLI # 20837OSI8 ...............................................................................................10
PLI # 20926OSI8 ...............................................................................................10
PLI # 20928OSI8 ...............................................................................................11
PLI # 20927OSI8 ...............................................................................................11
List of Products Installed During Setup ..............................................................11
Microsoft ............................................................................................................11
OSIsoft, 32-bit Installation Kit ............................................................................12
OSIsoft, 64-bit Installation Kit ............................................................................13
Fixes and Enhancements ......................................................................................14
Technical Support and Resources ......................................................................38
Overview
The PI Server 3.4.380 is a feature release, not a service pack release, introducing
major new functionality in several areas of the PI Server. The last feature release was
PR1 (3.4.375.38), which was the first version of the PI Server to provide High
Availability (HA). However, all PI Server releases are cumulative, so 3.4.380 continues to
improve upon the feature set and stability of the last release: PR1 SP2 (3.4.375.99).
The PI Server 3.4.380 is the first release to deliver a full integration with Microsoft
Windows Security and Active Directory, as part of a new security model, which is
intended to bring greater flexibility and manageability. Both authentication and
authorization have been thoroughly enhanced, resulting in the most secure PI Server
version to date. To learn about all the new security features delivered with this release,
please consult the guide Configuring PI Server Security.
This PI Server release follows the PI SDK 1.3.6 release that delivered the client
components necessary to implement single sign-on, as well as other aspects of the
3.4.380 security model. Only PI-SDK 1.3.6 needs to be installed on a client node in order
to take advantage of the security features offered in 3.4.380. Upgrades to client products
themselves are not required to take advantage of the features offered by 3.4.380.
In addition to the new security model, this PI Server release includes the following
major enhancements:
Setup Program—Secure configuration by default, with database consistency

checks during upgrade;
PI Server Backups—Added support for incremental backups, verified backups,
and a full backup history;
PI Message Log—New severity levels, sub-second precision timestamps, and
new searching capabilities;
PI Network Manager—Significant re-engineering to enhance stability and
performance, especially when handling a large number of concurrent
connections and connections across unreliable or slow networks;
PI Server Replication, HA— Certificate-based connection between PI Collective
members for improved security and continued support for Microsoft Cluster
Services (MSCS);
PI System Management Tools—Many new and improved SMT Plug-ins,
support for Heading Sets / Headings in PI MDB Builder;
General Scalability—Configurable file size limit on Point and Module
Databases beyond 2GB, default maximum PI Archive query increased to
1,500,000 events.
This release also includes fixes for a large number of issues that were reported and
identified in previous PI Server versions and that were not included in PR1 SP2. These
Page 1
issues were identified via a variety of sources: a lengthy beta program, widespread
internal testing at OSIsoft, monitoring of the PI Servers at Managed PI sites of our
Enterprise customers, monitoring of the PI Servers that constitute the Managed PI NOC
at OSIsoft, and feedback via OSIsoft Technical Support. To all of our customers, beta
participants, and partners – thank you for your contributions and continued support!
Please refer to the section Fixes and Enhancements below for details.
The PI Server 3.4.380 is available as both 32-bit and 64-bit setup kits for the Microsoft
Windows platform (Windows 2000 and above). This is the first PI Server release that is
officially supported for Windows Server 2008 R2, in both Full and Core installations.
Please refer to the section Supported Operating Systems below for details on platform
requirements.
OSIsoft strongly recommends testing any software release prior to use in a production
environment. Although a feature release may typically be riskier than a service pack
release, 3.4.380 should definitely be the PI Server version of choice for any new
installation or for any PI Server for which an upgrade has been delayed for several
years. For those customers working to implement or improve PI Server security either
because of regulatory compliance or other pressures, upgrading to 3.4.380 is a definite
must. For those customers in validated environments or that have particularly strict
and costly change-control procedures, upgrading to 3.4.380 is also definitely
worthwhile; however, if you are currently running PR1 SP1 or PR1 SP2, have no plans to
take immediate advantage of any of the new features, and are not currently
encountering any issue that has been fixed, you may find it prudent to wait for the
subsequent 3.4.380 service pack before upgrading.
Additional information and resources for the PI Server are available on the OSIsoft
Technical Support Web site:
http://techsupport.osisoft.com/Products/Servers/PI+Enterprise+Server+%283.x%29/
PI+Enterprise+Server+%283.x%29.htm
Supported Operating Systems

For production environments, the PI Server 3.4.380 is supported on the following
server operating systems:
Windows 2000, SP4 (x86)

Windows Server 2003 and 2003 R2, SP1 and above (x86, x64)
 Service Pack 2 (SP2) recommended
Windows Server 2008, SP1 and above (x86, x64)1
 All editions; Full and Core installations
 Service Pack 2 (SP2) recommended – refer to Known Issues with Windows
Server 2008/Vista below
Windows Server 2008 R2 (x64)1,2
Page 2
 All editions; Full and Core3 installations
For development and testing environments, the following client operating systems are
also supported:
Windows XP, SP2 and above (x86, x64)

Windows Vista, SP1 and above (x86, x64)1
 Service Pack 2 (SP2) recommended – refer to Known Issues with Windows
Server 2008/Vista below
Windows 7 (x86, x64)1,2
(1) Exception: Because VSS is not supported by Microsoft for WOW64, the 32-bit PI
Server is not supported on x64 versions of Windows 2008, Windows Server 2008
R2, Windows Vista, and Windows 7
(2) Because of their limited availability at the time of the release, Windows Server 2008
R2 and Windows 7 received preliminary qualification only. However, OSIsoft fully
supports PI Servers deployed on these operating systems. Complete qualification for
these operating systems will occur for the subsequent PI Server release.
(3) See Known Issues with Windows Server 2008 R2 Core below.
Hardware Virtualization Support
The PI Server is fully supported on virtualized operating systems when hosted on production-
grade virtualization solutions. Among these solutions are the following products:
Microsoft Hyper-V
VMware ESX and ESXi Servers
NOTE: Careful attention should be paid to the availability of underlying hardware
resources for the PI Server, especially if other applications or guest operating systems
will be competing for resources on the same hardware host. Disk I/O is especially
critical to the performance of the PI Server, as are CPU and memory. Network
bandwidth is generally not a bottleneck, but sufficient allocation is required.
Known Issues with Windows Server 2008/Vista
On Windows Server 2008 SP1, Vista, and Vista SP1, a known problem described in
Microsoft KB Article # 951246 (http://support.microsoft.com/kb/951246) and PLI #
16883OSI8 will cause your daily PI Server backup to stop functioning. Failure to resolve this
issue will significantly compromise your disaster recovery abilities, especially if any issue
goes unnoticed for a long period of time after the operating system is upgraded.
The problem in SP1 and earlier is that Task Scheduler fails to execute any task that has one or
more command line argument surrounded by double quotes (""). After every such task
Page 3
execution, the “Last Run Result” column in Task Scheduler will always display “(0x1)”. The
daily PI Server Backup scheduled task meets these criteria.
To resolve this issue, take one of the following actions.
Upgrade to SP2 of Windows Server 2008 or Vista. The problem is fixed in SP2.
Obtain the hotfix to SP1 from Microsoft. To get the Windows hotfix, contact
Microsoft Customer Support Services (free of charge) as directed in the KB article.
Edit the command line to the PI Server Backup scheduled task as described in the
workaround below.
WORKAROUND: If you do not obtain the hotfix or the service pack described above, you
will need to remove the double quotes from the BAT arguments used in the PI Server Backup
scheduled task. Only two arguments should be surrounded by double quotes: the backup path
and the cutoff date (optional).
Backup path:
 If the backup path does not contain spaces, then simply remove the
surrounding double quotes.
 If the backup path does contain spaces, replace the full path with the short
path and remove the surrounding double quotes. To determine the short
path, execute the command ‘dir /x’ from the parent directory of each part of
the path that contains spaces.
Cutoff date:
 If the cutoff date is not present, then no modifications are necessary.
 If the cutoff date is present and does not contain spaces, then simply remove
the surrounding double quotes.
 If the cutoff date is present and does contain spaces, then change the cutoff
date to some other value that does not require spaces and remove the
surrounding double quotes. If no such alternative value for cutoff date is
acceptable, then create a wrapper BAT script that invokes the original script
with the original arguments (including the double quotes) and then change
the scheduled task to invoke the new wrapper script.
Known Issues with Windows Server 2008 R2 Core
The PI Server setup kit will fail to install on Windows Server 2008 R2 Core. The
installation will fail during the installation of the PI-SDK. This problem is described in
PLI # 20832OSI8. The following workaround is available.
1. Create a directory then extract the files from the PI Server setup kit to that
directory. Before extracting the files, uncheck the checkbox next to “When done
unzipping open: .\setup.exe”.
2. Edit the setup.ini file that is delivered with the setup kit as follows. Append
“OSMASK_CORE=536870912” to entry 9 of section [COMMANDLINE]. This entry
Page 4
corresponds to the setup kit for the pisdk.msi. After the edit, entry 9 should look
like:
9 = REBOOT=Suppress ALLUSERS=1 /qb- SUPPRESS_PINS=1
PI_SERVER=localhost PI_ALIAS=localhost PI_TYPE=3 PI_PORT=5450
PI_USER=piadmin OSMASK_CORE=536870912
3. Run setup.exe from the extracted files.
Known Issues with Performance Counters
Beginning with PR1 SP2 (3.4.375.99), many long-standing issues with performance counters
have been resolved. The issues that remain are relatively minor and are summarized in this
section.
PLI # 20080OSI8
If the 32-bit PI Server is installed on a 64-bit operating system, you will need to perform
the following workaround in order to read the PI Performance Counters from a remote
machine:
1. Install the latest OSI prerequisite kit. This ensures that the 64-bit runtimes are
installed.
2. Obtain a 64-bit copy of pictrdll.dll from OSIsoft Technical Support (version
3.4.375.99/3.4.380.36 or later)
3. Install the new pictrldll.dll in the Windows\System32 directory.
4. Run the command "pidiag -lcks" from the PI\adm directory. (This command is new
in 3.4.375 SP2.)
PLI # 20050OSI8
Performance counter producers for PI Server processes may show up twice in the
browse dialog of the Performance Monitor tool on Windows XP (32-bit only) and
Windows 2000. This issue doesn't prevent collecting values from these producers, nor
does it affect operations of the PI PerfMon Interface. This is a minor regression of PLI #
16914OSI8. This issue will be addressed in a service pack release of the PI Server.
PLI # 20428OSI8
PI Performance Counters stay at 0 if the PI Perfmon Interface or the Performance
Monitor tool is started before the PI process being monitored. This problem is not a
regression in 3.4.380. This problem affects all previous PI Server versions.
PLI # 20769OSI8
Some performance counters may not be visible for 3-5 minutes after a fresh install.
Page 5
Choosing Between the 32-bit and 64-bit Setup Kits
The 64-bit installation kit is a separate download from the 32-bit installation kit. On
Windows Server 2003 x64, you can install the 32-bit PI Server, but for new installations,
OSIsoft recommends installing the 64-bit PI Server. On Windows Server 2008 x64, you
must install the 64-bit PI Server. Since Windows Server 2008 R2 is only available for
the x64 architecture, the 64-bit PI Server is the only option.
Unless your PI Server is running into the 2 GB memory limitation for 32-bit processes,
there is no immediate need to migrate to the 64-bit PI Server. If you are moving your PI
Server to new hardware, regardless of its size, OSIsoft recommends installing the 64-bit
PI Server to guarantee best performance.
Typically, the memory usage of the PI Server grows primarily with point count, among
other metrics such as concurrent users, data rates, or query complexity. For example,
the memory usage of the Archive Subsystem (for the read and write cache) starts
approaching the 2 GB limit usually around 500,000 PI Points.
Installation and Upgrade

The PI Server 3.4.380 is delivered as a standalone setup kit. Except as described under
Installation Prerequisites below, there is no need to install a previous version of the PI
Server before upgrading to 3.4.380.
This release comes with an updated PI Server Installation and Upgrade Guide (available
at http://techsupport.osisoft.com) you should follow to install 3.4.380 or upgrade any
PI Server version to 3.4.380. The document describes all upgrade situations, including
procedures to follow for a High Availability PI Server, or on a Windows Cluster.
IMPORTANT: The PI Server 3.4.380 does not support upgrading automatically a 32-bit
installation on Windows x64 to the 64-bit version of the PI Server. Please refer to the
section Migrate from 32-bit to 64-bit PI Server on the Same Computer of the PI Server
Installation and Upgrade Guide.
If you installed a beta version of 3.4.380, you can only directly upgrade to the 3.4.380.36
release from 3.4.380.33 (Beta 3).
Installation Prerequisites
If you are using the PI Buffer Subsystem on your interface nodes, make sure they
are running version 3.4.375.84 or later. Versions of the PI Buffer Subsystem
earlier than 3.4.375.84 are not compatible with PI Server 3.4.380. You should
check all PI Interface nodes and upgrade to PI Buffer Subsystem 3.4.375.84 if
needed.
Before upgrading, you must have a full backup of your PI Server that will not be
overwritten after the upgrade to 3.4.380. After upgrading to 3.4.380, the only
way to downgrade the PI Server is by restoring a PI Server backup that was
taken before the upgrade.
Page 6
MDAC v2.7, MSXML v6.0 Parser, .NET Framework 2.0 must be installed prior to
installing the PI Server installation kit. These requirements can be installed
with the appropriate prerequisite kit
(http://techsupport.osisoft.com/Products/Prerequisite+Kits/).
If you currently have PI Server version 3.0 or 3.1, you must first upgrade to 3.2
before upgrading to 3.4.380. You can upgrade directly from any version of 3.2,
3.3, or 3.4 to 3.4.380.
Upgrading PI Server Collectives
The PI Server PR1 (version 3.4.375.38) and subsequent service pack releases included
the support for High Availability through a PI Server Collective. A collective is composed
of a Primary node and one or more Secondary nodes sharing the same data and
configuration through replication. Collective members are running concurrently to
achieve N-way redundancy, which enables hot failover of PI client applications.
With proper configuration, N-1 nodes can be stopped without affecting the availability
of your overall PI System. Special considerations have to be taken when upgrading the
PI Server nodes.
In general, PI Server Service Packs can be applied on any node, Primary or Secondary,
and in any order without breaking any functionality. This was the case with both SP1
and SP2 of PR1. Although the overall upgrade sequence of a collective to 3.4.380 must
follow particular steps, rolling upgrades are still supported, with continuous data
collection throughout the entire upgrade.
The PI Server 3.4.380 introduces fundamental changes to the PI security model. As a

result, replication of configuration changes will halt if collective members are running a
mixture of 3.4.375 and 3.4.380. Additionally, the 3.4.380 setup program modifies
configuration during the upgrade of the Primary only. As a result, the overall upgrade
sequence of a collective must follow these steps:
1. Upgrade the Primary and validate functionality;

2. Upgrade a Secondary PI Server node;
3. Reinitialize the Secondary from the Primary node and verify PI Server replication;
4. Repeat steps 2 and 3 for each additional Secondary.
Please refer to the section Upgrade PI High Availability (PI HA) Servers of the PI Server
Installation and Upgrade Guide for the complete upgrade procedure.
Installing and Uninstalling on Windows Server Core
The uninstall instructions apply both to Windows Server 2008 Core and Windows Server
2008 R2 Core. For the installation instructions on Window Server 2008 R2 Core, please see
Known Issues with Windows Server 2008 R2 Core above.
Page 7
Installation Instructions
2. Run setup.exe from the extracted files.
Uninstall Instructions
In the directory where you extracted the files from the PI Server setup kit, look for the
program piuninstall.exe. To uninstall the PI Server, type the following command.
piuninstall.exe –msi
Silent Installation or Upgrade
The install kit for PI Server 3.4.380 provides a command file called silent.bat for silent
installation and upgrade. To use the command file:
1. Prepare for installation or upgrade by following the procedures in the PI Server
Installation and Upgrade Guide. Use this information to decide how to customize the
silent.ini file.
3. Customize the silent.ini file as needed. Instructions for the customization are located
in the silent.ini file silent.ini itself.
4. Check for OSIsoft prerequisites by running silent.bat with the -check option. For
example:
c:\PIServerInstall\silent.bat -check
5. After you have verified that prerequisites are installed, use silent.bat to run the
PI Server Setup program. For example:
c:\PIServerInstall\silent.bat -install
Documentation
Because of time constraints, some manuals could not be completed at the time of release. All
manuals that require updates will be available for download from the OSIsoft Technical
support web site shortly after release. See the table below for details.
Document Comments
Configuring PI Server Security New or updated with the 3.4.380.36
release.
PI Server Installation and Upgrade Guide
Introduction to PI System Management
Page 8
PINet and PIonPINet User Guide
PI Server Reference Guide Last updated for the 3.4.370.52 release
of the PI Server.
PI Server Application User Guide
PI Server System Management Guide
Auditing the PI Server
High Availability and PI Server Replication Last updated for the PR1 release of the
PI Server.
High Availability Advanced User Guide
The manual Configuring PI Server
High Availability User Guide
Security contains up-to-date
information on High Availability.
Known Issues
For a complete list of known issues in the PI Server, please refer to the following
address on OSIsoft technical website:
http://techsupport.osisoft.com/techsupport/nontemplates/Known%20Issues/Issues.a
spx?foundInProduct=PI3&issueType=Known+Issues
A partial list of known issues is reproduced below. Some are reproduced here because
of their significance. Others are listed because they were first discovered while testing
3.4.380 or because they are particularly pertinent to 3.4.380.
PLI # 20555OSI8
PI Server subsystems may crash at shutdown if an RPC is still in progress. Even if rare,
this is most likely to occur with the core subsystems (e.g. PIARCHSS, PISNAPSS,
PIBASESS, etc.) because these are often the busiest subsystems on any given PI Server.
This problem is not a regression in 3.4.380. This problem affects all previous PI Server
versions.
PLI # 20761OSI8
Error messages the first time starting the PI server, IDs: 3007, 6075, 2075, 2050, 2014.
The above messages are expected the first time only starting the PI server, for the
following reasons:
1) License manager starts before Base, and Base stores the server's role
(Primary,Secondary, or Non-Replicated), License manager will report (Message ID:
3007) until Base determines the role.
Page 9
2) The installation kit doesn't include certain Base confirmation files, instead relying on
Base itself to create them. This is why Base reports certain files missing initially
(Message ID: 6075)
3) When Archive starts up the first time, it must initialize the Primary archive, during
this time archiving is temporarily is disabled (Message ID: 2075, 2050). Once the
Primary archive is initialized archiving will be enabled again automatically.
4) The Shutdown subsystem attempts to write the System digital 'Shutdown' to tags
indicating the system has been down, however the first time up it tries to write the
digital before the start of the first archive (Message ID: 2014)
The problem with error messages being written the first time the PI Server is started is
not a regression in 3.4.380. However, in 3.4.380 these errors may now stand out
because one can search the message log by severity level.
PLI # 20773OSI8
When PI AutoPointSync is installed on a 64-bit version of Windows, the PI APS

Synchronization Trigger (version 2.0.2.0 and earlier) service fails. When executing as a
64-bit program, the PI APS Synchronization Trigger service requires 64-bit versions of
several DLLs that either may not be installed or have no 64-bit version and the service
fails because it is unable to load the required dependent libraries.
WORKAROUND: PIAPSSyncTrigger.exe version 2.0.3.0 is available for download as a

"patch" for PI AutoPointSync versions 1.2.4.0 and 1.2.5.0 when installed on a 64-bit
version of Windows. If PI AutoPointSync is installed on a 32-bit version of Windows, it is
not necessary to install PI APS Synchronization Trigger version 2.0.3.0. See Support
Bulletin "PI AutoPointSync Syncronization Trigger Patch for 64-bit Windows is
released" http://techsupport.osisoft.com/Bulletins/4/2326940a-4858-4e13-b2aa-
21eb5f1b829d.htm
PLI # 20837OSI8
If the 64-bit PI-SDK is installed on a 32-bit PINS node, the 32-bit PI Server can be
subsequently installed. The 32-bit installation should detect that this is a PINS node and
prevent the installation.
PLI # 20926OSI8
The Batch Subsystem does not fully support the new security attributes. PI Batch
Subsystem (BSS) units have several security attributes: UnitOwner, UnitGroup,
UnitAccess, DataOwner, DataGroup, DataAccess.
These attributes map directly to the Pt* and Data* attributes of the underlying pibaN
point for the unit.
Page 10
However, BSS does not have a UnitSecurity or a DataSecurity attribute; thus, BSS units
cannot fully represent the new ACLs in 3.4.380.
It is possible to just ignore the unit attributes and always manipulate the Pt* and Data*
attributes on the underlying pibaN point, but this is confusing and hard to remember
over time.
PLI # 20928OSI8
In an HA collective, on a Secondary, with auditing enabled, the Snapshot and Archive

audit records may be missing user information (userid = 0) if Windows authentication
is used. This can happen for several reasons:
(1) replication is delayed or broken and the authentication record for the Windows user
has yet to be created on the Secondary
(2) the Windows user has never logged in to the Primary, and only logged in to the
Secondary
(3) the Windows user is from a domain that is not trusted on the Primary
(4) the Windows user is a local Windows user that is not known on the Primary
This cannot happen for creator / changer information on points and modules.
This cannot happen for any audit record generated by the PI Base Subsystem.
PLI # 20927OSI8
The MDB editor (in PI SMT Module Database) fails to add more than one Heading to a
HeadingSet at a time.
List of Products Installed During Setup

The 3.4.380 installation kit redistributes software components and files from both
OSIsoft and other vendors. This section summarizes these redistributables.
Microsoft
Product Software Version
Microsoft Visual C++ Version 8.0.50727.762

Runtimes
Microsoft ATL Version 8.0.50727.762
Page 11
OSIsoft, 32-bit Installation Kit
Product Software Version Installation Kit Version
PI Server 3.4.380.36 3.4.380.36

(Archive, Snap, Base,
License, SQL, Backup,
Message, Netmgr, Updmgr)
PI-SDK + 1.3.6.363 1.3.6.364
PI-SDK patch (KB20866)
PI-ICU 1.4.7.0 1.4.7.0
PI-APS Interface Registration 1.2.7.0 1.2.7.0
DLL
PI-APS 1.2.5.0 1.2.5.0
PI Generic Names DLL 1.2.10.0 1.2.10.0
PI Random Interface 3.4.375.38 3.4.375.38
PI Random Interface ICU 3.4.375.38 3.4.375.38
PI Ramp-Soak Interface 3.4.375.38 3.4.375.38
PI Ramp-Soak Interface ICU 3.4.375.38 3.4.375.38
PI Perfmon Basic Interface 1.4.3.0 1.4.3.0
PI Perfmon Interface ICU 1.4.0.0 1.4.0.0
PI Ping Basic Interface 1.6.3.0 1.6.3.0
PI Ping Interface ICU 1.6.2.0 1.6.2.0
PI SNMP Basic Interface 1.4.2.0 1.4.2.0
PI SNMP Interface ICU 1.3.2.0 1.3.2.0
PI Batch Generator Interface 2.0.5.1 2.0.5.1
PI Interface Status Utility 1.6.3.0 1.6.3.0
PI Interface Status Utility ICU 1.6.3.0 1.6.3.0
PI-System Management 3.3.1.3 3.3.1.3
Tools
PI Collective Manager 1.1.0.2 1.1.0.2
PI Tag Configurator 2.1.3.0 2.1.3.0
PI Module Database Builder 1.2.1.3 1.2.1.3
PI Advanced Server Apps 3.4.380.36 3.4.380.36
(total, alarm, performance
equations, re-calculator)
PI Batch Subsystem 3.4.380.36 3.4.380.36
Page 12
OSIsoft, 64-bit Installation Kit
Product Software Version Installation Kit Version
PI Server 3.4.380.36 3.4.380.36

(Archive, Snap, Base,
License, SQL, Backup,
Message, Netmgr, Updmgr)
PI-SDK + 1.3.6.363 1.3.6.364
PI-SDK patch (KB20866)
PI-ICU 1.4.7.0 1.4.7.0
PI-APS Interface Registration 1.2.7.0 1.2.7.0
DLL
PI-APS 1.2.5.0 1.2.5.0
PI Generic Names DLL 1.2.10.0 1.2.10.0
PI Random Interface 3.4.364.70 3.4.364.70
PI Random Interface ICU 3.4.375.38 3.4.375.38
PI Ramp-Soak Interface 3.4.364.70 3.4.364.70
PI Ramp-Soak Interface ICU 3.4.375.38 3.4.375.38
PI Perfmon Basic Interface 1.4.3.0 1.4.3.0
PI Perfmon Interface ICU 1.4.0.0 1.4.0.0
PI Ping Basic Interface 1.6.3.0 1.6.3.0
PI Ping Interface ICU 1.6.2.0 1.6.2.0
PI SNMP Basic Interface 1.4.2.0 1.4.2.0
PI SNMP Interface ICU 1.3.2.0 1.3.2.0
PI Batch Generator Interface 2.0.5.1 2.0.5.1
PI Interface Status Utility 1.6.3.0 1.6.3.0
PI Interface Status Utility ICU 1.6.3.0 1.6.3.0
PI-System Management 3.3.1.3 3.3.1.3
Tools
PI Collective Manager 1.1.0.2 1.1.0.2
PI Tag Configurator 2.1.3.0 2.1.3.0
PI Module Database Builder 1.2.1.3 1.2.1.3
PI Advanced Server Apps 3.4.380.36 3.4.380.36
(total, alarm, performance
equations, re-calculator)
PI Batch Subsystem 3.4.380.36 3.4.380.36
Page 13
Fixes and Enhancements
The section describes the defects and enhancements included in this release. The list is
divided into sections based on topic (e.g. "HA" for high availability and replication) or
affected subsystem (e.g. Archive). For further information on each defect or
enhancement, please visit the OSIsoft Technical Support website
(http://techsupport.osisoft.com) and search for the PLI that references the issue. The
reference number for each PLI is in parentheses after the description of each defect or
enhancement.
If you need further information about any fix or enhancement or some other aspect of
3.4.380, please contact OSIsoft Technical Support.
Archive
Defect
When performing offline archive reprocessing of an "auto-dynamic" archive, the contents of

the primary record of points that don't have index records may be copied twice in the output
archive, resulting in duplicate data in the output archive. This behavior has been corrected.
(20076OSI8)
The archive shift logic has been updated so that a registered, empty archive is no longer
required for automatic archive creation to work. In addition, a new tuning parameter has been
created to help govern how the archive subsystem should react should there be a failure to
auto create an archive during a shift. The tuning parameter,
Archive_OverwriteDataOnAutoShiftFailure, defaults to a value of 1 (true). If automatic archive
creation fails during a shift, the archive subsystem will use the standard shift algorithm to pick
an existing archive to reuse as the new primary archive. If the tuning parameter is set to 0
(false) and auto archive creation fails during a shift without an empty target archive, the
archive subsystem will stop archiving. (4798OSI8)
Under exceptional circumstances, the Archive Subsystem would temporarily stop processing
data from the Event Queue. This issue could occur when high volumes of data were backfilled
to very few points (less than 4, or the number of Archive Flush threads). Processing of data
from the Event Queue would stall for up to 4.5 minutes. No data loss would occur, however,
because queued data would automatically be recovered at the end of the delay. Also, PI Server
availability would not compromised. This issue is now resolved. (20345OSI8)
If the tuning parameter Archive_MaxWriteCachePerPoint was set to a value of 0, the Archive

Subsystem would not process any archive values from the event queue. This has been
corrected. (20496OSI8)
The timeout parameter ArcMaxCollect could previously be set to a value of 0 which would
result in all archive queries returning an error. This behavior has been fixed. The parameter
can now only accept values between 150,000 and 2147483647. The parameter defaults to a
value of 1,500,000. (20503OSI8)
When running the offline archive to reprocess a corrupt archive, the archive process could exit
prematurely after raising an exception with the text "Attempt to dirty a record in cache!." The
same exception could also be raised when running PIDIAG -ARCHK. This problem has been
fixed. (14307OSI8)
Page 14
Changing and removing annotations from the archive would not be audited. This problem has
been fixed. (4966)
Enhancement
Wildcard characters can now be used with the PIARTOOL -AU command. (20115OSI8)
Audit
Defect
At startup / shutdown of a subsystem with auditing enabled, one more audit record would be
reported in the PI Server Message log than would actually exist in the audit file. This has been
fixed. (9424OSI8)
Using the -DBMASK option with PIDIAG -XA would result in “[-1] Generic Error or PI 2.x Point
Out of Range or Not Defined” when the last audit record that was examined did not match the
DBMASK. The actual audit export would be successful in spite of the spurious error message.
This problem has been fixed. The spurious error message is no longer displayed. (9429OSI8)
Enhancement
Previously, changes to security of modules, heading sets, and headings were not properly
audited. The attribute "SecureObject" would show up as an "unknownType". This has been
fixed. Security changes for modules, heading sets, and headings now appear in the audit
record as the attribute names "Owner", "Group", "Access", and "Security". (13207OSI8)
Backup
Defect
If pibackup.bat was launched when pinetmgr.exe was not running, the pibackup.bat script
would hang. This problem has been fixed. (10778OSI8)
The \PI\dat\localhost.tz time zone information file is now included in the PI Server backup.
(19184OSI8)
The pibackup.bat script would fail if PI was installed to a directory with spaces (e.g.
“D:\Program Files\PI”). The backup script would also fail if the PISERVER environment
variable was enclosed in double quotes (e.g. PISERVER="D:\Program Files\PI\"). These
problems have been fixed. (16209OSI8)
Backups would fail if a folder with a name starting with "pimsg_" existed in the \pi\log
directory. For example, if a customer created a folder with a name of
“D:\pi\log\pimsg_foldername,” the following error would appear in the PI Server Message log:
"Error [5] Access is denied., occurred while copying D:\PI\log\pimsg_foldername to
d:\testtest\log\pimsg_whatever for VSS backup." This problem has been fixed. (18753OSI8)
The -INSTALL flag for pibackup.bat is no longer case sensitive. (17942OSI8)
Page 15
When the backup script was run on Windows 2000, error -16841 was written to the backup-
specific log, even when the backup was successful. This error message is no longer written.
(15604OSI8)
If a UNC backup path was passed to PIBACKUP.BAT, the backup would fail. For example, the
command "pibackup.bat \\computername\backupdir" would fail. This problem has been
fixed. (14764OSI8)
Audit files were not backed up unless auditing was turned on. In addition, audit files that had
been renamed as a result of an audit database shift were also not backed up. This problem has
been fixed. All audit files in the \pi\log directory with a name of the form pibasessAudit.dat*,
pisnapssAudit.dat*, and piarchssAudit.dat* are now backed up whether or not auditing is
turned on. (9032OSI8)
Aborting a backup would leave partially copied files in the backup directory. This problem has
been fixed. (12504OSI8)
Enhancement
PI Server backups now perform a verification step. Archives are verified with the "pidiag -
archk" command. The snapshot database is verified with the "pidiag -fb piarcmem.dat"
command. The databases belonging to the PI Base Subsystem are verified with "pibasess -
verifydb". The number of archives to verify is determined by the BackupVerification_NumArch
tuning parameter, which is set to 1 archive by default. Verification is enabled by default. It can
be disabled by setting the BackupVerification tuning parameter to 0. (12450OSI8)
The PI Backup Subsystem now checks for available disk space before attempting a backup. By
default, if 256 MB or less space will remain after the backup has completed, the backup will
abort. The low disk space tolerance can be adjusted with the backup_LowDiskSpaceMB
turning parameter. (19054OSI8)
The pisitebackup.bat.example has been enhanced. This file is installed by the PI Server to the
\pi\adm folder. Simply by renaming the file to pisitebackup.bat, the script will automatically
backup all files ending in .bat, .log, .ini, .txt, and .sql from the 32-bit (and, if the 64-bit PI Server
is installed, from the 64-bit) PIPC directories and sub-directories. The files will be backed up
under the "sitebackup" folder in the PI Server backup directory. With minimal changes to the
script, the pisitebackup,bat script can also be configured to perform a second task, which is to
copy the entire PI Server backup directory to a distinct folder on a remote machine every
night. A similar option was provided in the pisitebackup.bat.example that was delivered with
3.4.375, but only the modified files under the PI Server backup directory were copied each
night. Although the mechanism in the 3.4.375 pisitebackup.bat.example script saved disk
space, it was overly complex and restoration procedure was difficult to explain. As
documented in the pisitebackup.bat.example itself, this second task should be implemented
only if third-party backup software is not available. (18735OSI8)
A backup can now be performed with 0 archives. For example, the command "piartool -backup
c:\testbackup -numarch 0" will backup all databases except archive files. This feature is useful
for the collective manager when only configuration information needs to be re-initialized
between the primary and the secondary. (18024OSI8)
If a file of the same name, last modified date, and file size is already in the backup directory, the
file copy will be skipped, provided that the file is not verified (see PLI 12450OSI8 in these
Page 16
release notes). In PI Server version 3.4.375, file size was not taking into account when
determining which file copies to skip. Also in version 3.4.375, file copies were skipped only for
so-called "incremental" backups. The meaning of incremental backups has changed in 3.4.380,
as described in PLI 13589OSI8 in these release notes. The same algorithm for determining
which file copies to skip is now applied to all backup types (Full, Incremental, Differential,
Copy, and Numarch/Cutoff). (13495OSI8)
In 3.4.375, if a VSS backup failed to start, the PI Backup Subsystem would attempt to do a non-
VSS backup instead. Typically, the customer would have no idea that there was any failure
because no errors would be written to the backup-specific log (assuming that the non-VSS
backup was successful). The customer would have no reason to look for the VSS error
messages that were written to the PI Message Log. In 3.4.380, a non-VSS backup will still be
performed if the VSS backup fails, but the customer will now see more evidence that a separate
VSS backup failed. First, from the new Backup History plug-in in PI-SMT, customers will be
able to see a failed VSS backup immediately followed by a successful non-VSS backup. Second,
one will see the failed VSS backup in the backup-specific log. The error status of the failed VSS
backups will be -16911: "The backup failed due to a failure in Volume Shadow Copy Services
(VSS)." Third, the "Failed Backups" Windows performance counter for the PI Backup
Subsystem will be incremented by 1. (20664OSI8)
When archives are backed up, the "Backup Time" in the header of the archives in the backup
directory should now match the "Backup Time" of the online archives for the backup that was
just performed. In other words, the "Backup Time" as displayed by "pidiag -ahd" of a backed
up archive should match the "Backup Time" of the corresponding archive as displayed by
"piartool -al." Prior to this fix, the backup time of the archives in the backup directory were not
updated. The purpose of this enhancement is to prevent a potentially large incremental backup
after restoring the PI Server. After the restore, the last backup time of all restored archives
should be more recent than the last modified time, provided that the archives were backed up
while 3.4.380 was installed. (18917OSI8)
Customers should now be able to do Incremental, Differential, Full, and Copy backups of the PI
Server with Symantec (VERITAS) Backup Exec version 11d or greater. A white paper titled "PI
Server Backups with Symantec Backup Exec" is available for download from OSIsoft technical
support. (9479OSI8)
All backups that are performed with PI Collective Manager and the new backup Plug-In in PI-
SMT are now COPY backups. A COPY backup is a backup that does not change the last backup
time of the archive files that are included in the backup. It is important to use COPY backups
for this purpose to avoid compromising the new incremental backups that are now available in
3.4.380. For the new incremental backups, only archives that have been modified since the last
backup time are selected for backup. If the last backup time was modified outside of your
regularly scheduled backups (such as with Collective Manager or the backup Plug-In), some
archives that should be included in your regularly scheduled backups may not be included.
(14823OSI8)
Incremental backups are now available in 3.4.380. Previously, in 3.4.375, a form of

incremental backups was available, but the configuration was not intuitive. If you are
upgrading to 3.4.380 from 3.4.370 or greater, your backups will continue to work like they did
before the upgrade. To migrate to the new incremental backups, you can uninstall and then re-
install the PI Server Backup scheduled task with the \pi\adm\pibackup.bat script. If you are
upgrading to 3.4.380 from a version of PI prior to 3.4.370, you will need to reconfigure your
backups or else your backups will cease to work. (13589OSI8)
Page 17
Several WindowsPerformance counters are now available for the PI Backup Subsystem. These
include “Aborted Backups”, “Backup In Progress”, “Backups Started”, “Backups Started non-
Component”, “Backups Started non-VSS”, “Failed Backups”, “Last Backup Copy Failures”, “Last
Backup Duration”, “Last Backup Failed”, “Last Backup Files Copied”, “Last Backup Files
Skipped”, “Last Backup Init Duration”, “Last Backup Megabytes Copied”, “Last Backup
PrepareBackup To Freeze Duration”, “Last Backup Total File Count”, “Last VSS Freeze
Duration”, “Last VSS Freeze Transition”, and “Verification Failures.” (20937OSI8)
Informational
Backups will not work on Windows Server 2008 SP1 unless the workaround described in PLI
16883OSI8 is followed. This problem does not affect Windows Server 2008 SP2 or greater.
(16883OSI8)
Base
Defect
When a digital state set could not be created due to a permissions problem, the error message
was not appropriate. For the PI-SDK, the error message was "Unable to retrieve error
information." For piconfig, the error message was "[-10707] Digital set number mismatch
during type coercion." This problem has been fixed. (15046OSI8)
Previously, viewing digital data for a point had always required read access to PIDS
DBsecurity. Now read access to PIPOINT DBSecurity also implies read access to PIDS
DBsecurity, effectively relaxing the requirement for those users configured with read access to
the point’s data.(19399OSI8)
The Step attribute for PI Points with PointTypes of digital, string and timestamp is now always
set to 1. The Step attribute cannot be set to 0 for these points. Plotting algorithms in client
applications use the step attribute to determine trend behavior. Previously it was ambiguous
how a Step attribute of 0 should be handled by client applications for non-numeric points.
Now that the Step attribute is always 1 for non-numeric PI Points, this ambiguity is eliminated.
(15403OSI8)
The ability to edit and delete AttributeSets and Point Classes was first added in version
3.4.370.52 of the PI Server. These operations were disabled in all 3.4.375 versions. Attempts
to edit or delete AttributeSets and Point Classes would fail with the error "[-10008]
Unsupported or Unimplemented Call.". This functionality has been restored in the 3.4.380
release. (13075OSI8)
A new installation of the PI Server followed by a restart of the PI Server would sometimes
result in -10400 errors in the pipc.log from interfaces on the local PI Server node (i.e.
Random/Rmp_Sk/PIpeschd). The -10400 errors occurred if the interfaces connected before
the PI Base Subsystem was able to create the default trusts. This problem is now fixed. The
server now temporarily goes into standalone mode until the Base subsystem has had a chance
to create the trusts and process the pirunonce.dif. See related PLI #19528OSI8 in these release
notes. (19454OSI8)
Enhancement
Page 18
In PI 3.4.375, several trusts were created by default when the PI Base Subsystem was started.
These included the loopback trust (!Proxy_127!) and a trust for the FQDN of the server. In a
collective one additional trust was created per collective member. The FQDN trusts were
required by interfaces running on the PI server, as well as the Base subsystem and License
manager on secondary servers. In PI 3.4.380 and later the FQDN trusts are no longer created
by default because (1) PINetmgr allows all local connections to use the Loopback trust and
because (2) Collectives have switched to certificate based authentication for the Secondary
servers connecting to the Primary. Although only the loopback trust is now created by default,
this new default can still be overridden by the AutoTrustConfig tuning parameter.
AutoTrustConfig is a bitmask: 0 = NONE, 1 = Loopback, 2 = Localhost, 4 = IPaddr, 8 =
Hostname, 16 = Fully Qualified Domain Name (FQDN), 127 = v3.4.370 Compatible, 255 = All,
17 = LoopBack + FQDN”. (20057OSI8)
A new command "pibasess -verifydb" is available. The main purpose of the verifydb command
is for verification of databases during backup. If the verification passes, the PI Base Subsystem
will be able to load the databases on startup if the backup is restored. (14469OSI8)
There are several new entries in DBsecurity table. Also, all old and all new entries now contain
a read-only description that can be viewed via the “Database Security” Plug-In in SMT. For
new installations, the piadmin account and the piadmins group has read and write permissions
to all entries in the DBsecurity table. For upgrades, existing entries will inherit from the
previous installation. The new entries in the DBsecurity table include the following.
PIAUDIT - Controls Read access to Audit info. For example, read access is required to take an
audit file offline with the “piartool –subsysbackup” command because the offline audit file can
be subsequently dumped to XML with the “pidiag –xa” command. Read access is also needed
for using PI-Audit Viewer.
PITUNING - Controls access to the timeout and firewall tables. Previously this was controlled
by the DBSEC entry.
PIBATCHLEGACY - Control access to configuration/viewing of the old batch system. Previously

this was hard coded to the default, where only piadmin had write permissions.
PIMSGSS - Read and write access to the message log, For example using pigetmsg requires
read access. By default world write access is granted so that anyone can write messages.
Previously there was no access control in this area.
PIBACKUP - Controls access to initiating backup or viewing backup status/info. Write access is
required in order to start a backup.
(19729OSI8)
The command-line usage output (pibasess.exe -?) for the PI Base Subsystem now gives a
summary of the various commands it supports, such as -snapfix, -mdbfix, -copydb, and -
dumpupr. (14623OSI8)
The timeout parameter "WindowsAuthentication" has been renamed to

"Base_LookupSIDForTrust" to avoid confusion with the new Windows authentication provided
by PI SDK 1.3.6.x and the 3.4.380 PI Server. (19577OSI8)
Page 19
An individual PI Trust can now be disabled without being deleted, which can be very useful
during troubleshooting. When disabled, the trust is excluded from authentication. A trust can
be disabled with either piconfig (by setting the trust's flags = 1) or SMT Mappings & Trusts
Editor (by checking the "Trust is disabled" box). (11128OSI8)
Batch Database
Defect
In all PI Server 3.4 versions, the PI Archive Subsystem may throw a "PIarray out of bounds"
message box or terminate unexpectedly when accessing an internal structure for maintaining
Batch Database (BDB) information. This is most likely to occur either shortly after reboot or
when new PIUnits are being added or de-commissioned while BDB queries are being
processed simultaneously. If you're not using the BDB, then you're not affected. This issue has
now been fixed. (20674OSI8)
Equations
Defect
pipeschd.exe -v reports version "3.4.370.82" whereas the output from piversion -v and the
Windows file version for pipeschd.exe reports the correct release version. This defect has
been corrected. pipeschd.exe -v now reports the correct released version number.
(20278OSI8)
General
Defect
PIconfig allows setting the number of display digits for fractional seconds. The piconfig
command for doing this, timf, would not honor values less than 2. For example, the following
piconfig command would incorrectly display 2 sub-second decimals instead of 1.
Command:
piconfig timf 1,F ostru tag,time,value select tag=timformat_command_test_tag ends
Incorrect output with 2 sub-second decimals:

timformat_command_test_tag,24-Nov-03 00:00:00.12,1
This problem has been fixed. Any precision between 0-8 can now be specified. (4656OSI8)
The pisrvstart.bat and pisrvstop.bat scripts no longer need to be run from the \pi\adm
directory. Because of this change, one can now run these scripts by right-clicking on them
from Windows Explorer and selecting "Open" or "Run as administrator" from the right-click
menu. The "Run as administrator" option is available starting with Windows Server 2008. The
ability to right-click and "Run as administrator" is especially convenient for Windows Server
2008 and greater because the pisrvstart.bat and pisrvstop.bat scripts must be run from an
Page 20
administrative command prompt on these platforms. If on Windows Server 2008 and greater
one does not run the pisrvstart.bat and pisrvstop.bat scripts as administrator, subsystems will
fail to start with error "System error 5 has occurred" and "Access is denied." (15404OSI8)
The batch, total, and alarm subsystems could crash on shutdown while the PI Server was in
standalone mode. This problem has been fixed. (16215OSI8)
On a Windows 2000 machine where HP/Compaq Insight Manager was being run, Perflib would
report many 1010 error messages in the Windows Application event log regarding an error in
pictrdll.dll. In the following example message "X" is any PI Subsystem:
The Collect Procedure for the "X" service in DLL "d:\program

files\pipc\bin\pictrdll.dll" generated an exception or returned an invalid
status. Performance data returned by counter DLL will be not be returned in
Perf Data Block. Exception or status code returned is data DWORD 0.
In 3.4.380, only a single error message indicating a problem will now be reported in the
Windows Application Event log. The error will indicate that the counters have been disabled.
Although the messages have been throttled, the only known fix for getting performance
counters to work again is to disable the Compaq/HP Insight Manager. (19251OSI8)
For new installations, the point database and the module database are no longer limited to 2
GB in size. The new default size limits are 16 GB for the point database and 32 GB for the
module database. For upgrades, the size limit is still 2 GB, unless the databases are manually
converted to use a different byte alignment. If these size limits need to be increased, please
contact OSIsoft Technical Support. For archives files, the new default size limit for annotation
files has been increased from 2 GB to 8 GB. The new size limit for annotation files applies both
to newly installed PI Servers and to upgraded PI Servers. (7762OSI8)
In all 3.4.375 versions of the PI Server, any PI3 subsystem (e.g. pinetmgr, pilicmgr, pibasess,
pisnapss, piarchss, etc.) or any PI3 application (e.g. piartool, piconfig, pigetmsg, etc.) would exit
if the timeout table parameter SBHThreshold was set to a value greater than 1016. Since the
SBHThreshold table parameter does not exist by default, this issue would typically occur only
on PI Servers that were at one time running PI Server version 3.2 or 3.3, where setting
SBHThreshold may have alleviated some issues. Explicit use of this parameter is no longer
recommended for newer PI Server versions on newer operating systems. Below is the
description of some sample error messages that would be written to the Windows Application
Event Log.
Faulting application pinetmgr.exe, version 3.4.375.38, faulting module

msvcr80.dll, version 8.0.50727.91, fault address 0x00006709. Faulting
application piartool.exe, version 3.4.375.38, faulting module msvcr80.dll,
version 8.0.50727.91, fault address 0x00006709.
The workaround is to remove the SBHThreshold parameter from the timeout table, or set it to
0. This can be done with an older version of PICONFIG that does not require PINetMgr or by
editing the file on another PI Server that does not have this issue. The file that stores the
timeout table entries is \PI\dat\pitimeout.tbl. This problem has been fixed. (14417OSI8)
Page 21
Enhancement
All PI Server "exe" and "dll" files now contain a manifest that defines their UAC requested
execution level to be "asInvoker". This is to satisfy TC3.1.1 of the Windows 2008 Certification
testing. (16105OSI8)
All “exe” and “dll” files that are installed by the PI Server now have a digital signature.
(15996OSI8)
HA
Defect
In 3.4.375.38 and later, if a new PI User was created and then immediately (within ~1 second)
used as the piuser for a new trust or an existing trust, the trust could fail to replicate with the
error "[-12002] Code Not Found in Pint." This issue has been fixed. (13204OSI8)
When pibufss was connected to the PI server and sending data, setting the server to
standalone mode (piartool -sys -standalone on) would not cause pibufss to disconnect from
the PI Server. This problem has been fixed. (13039OSI8)
Enhancement
Upon initial startup of a newly installed PI Server, the PI Server is now put in standalone mode
until the pirunonce.dif has been run and the default trusts have been created. See also PLI
#19454OSI8 in these release notes. (19528OSI8)
Informational
Starting in PI 3.4.380, PI HA Collectives use a certificate-based authentication mechanism

between members to avoid depending on trusts. When the Primary Server ID or Collective ID
is changed, the certificate is regenerated, and the secondary servers much be reinitialized. A
Warning message (ID 1041) is written to the PI Message Log indicating re-initialization is
necessary. (20283OSI8)
Installation
Defect
The PI-ICU has been removed from the OEM base historian installation kit. (20176OSI8)
When the OSIsoft MS Runtime Redistributables (MSRuntimes.msi and MSRuntimes_X64.msi)
Page 22
require a reboot, the setup kit will now prompt for a reboot before continuing with the PI
Server installation. Without the reboot, the installation of piserver.msi (x86) or
piserver_x64.msi (x64) could fail. In PR1 SP2 (3.4.375.99) the installation kit would reboot the
computer without prompting. Prior to PR1 SP2, the setup could simply fail during the
installation if the installation of the runtimes required a reboot. (20052OSI8)
If the PI Server installation kit is not run from a privileged account, the following error
message will now be displayed when the setup kit is launched: "You must run this installation
kit as administrator. If you are running on Vista/Server 2008 or greater, you must also run the
installation from an elevated command prompt." (17571OSI8)
The installation of the 64-bit PI Server could fail with the following popup dialog: "Error 1721.
There is a problem with this Windows Installer Package. A program required for this install to
complete could not be run. Contact your support Personnel or your package vendor." This
problem has been fixed by installing the MSRuntimes.msi and MSRuntimes_X64.msi before the
piserver_x64.msi is installed. Note that the 1721 error can still occur if either the
MSRuntimes.msi or MSRuntimes_X64.msi require and if the customer ignores the popup dialog
that requests a reboot. (19770OSI8)
The installation kit can appear to hang at the end of setup with 0 seconds remaining. This is
because the setup kit includes the Microsoft Visual Studio 8 runtime dlls. The runtime dlls have
be removed from the setup kit to eliminate this problem. The runtimes are now installed by
MSRuntimes.msi and MSRuntimes_x64.msi instead. If you are upgrading the PI Server from
version 3.4.375 or earlier, the 3.4.380 installation kit may still appear to hang with 0 seconds
remaining. This is because the runtimes were included in the previous setup kit. (20510OSI8)
The x64 installation kit used to give an option to do a "Typical", "Complete", or a "Custom"
installation. The option to do a "Complete" installation has been removed because it was the
same as "Typical". All features are installed when "Typical" is selected. To remove optional
features, one can still do a "Custom" install. (20505OSI8)
If you had upgraded from 3.3.362.47 at some point, the PI SNMP ICU Control (PISNMP) would
remain in Add/Remove Programs after uninstalling the PI Server. This problem has been
fixed. (18754OSI8)
The x64 PI Server setup kit now supports installations on Microsoft Clusters. (17899OSI8)
If the x64 PI Server was repaired from Add/Remove programs in the Windows Control panel, a
trailing backslash was appended to the registry value "InstallationPath" under the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\PISystem\PI. After the next restart of any subsystem
that registers for backup, VSS backups would fail. The following errors would appear in the
backup log: "Backup failed. Error [123] The filename, directory name, or volume label syntax is
incorrect." This problem has been fixed. (17770OSI8)
Page 23
On the PI Server Setup/User Information Dialog, there was an option to install for "Anyone
who uses this computer" or "For only the user who is performing the installation." These
options have been removed. Now the PI Server is always installed with the first option.
(17469OSI8)
When upgrading from 3.4.370 on Windows Server 2003, the PI Server Backup scheduled task
should preserve the 3.4.370 behavior of using ntbackup.exe for backing up the PI Server. This
behavior was not being preserved on a cluster. This problem has been fixed. (17459OSI8)
The PI Server setup kit would fail if a later version of piudsrdr.exe was installed than was being
delivered by the installation kit. This problem has been fixed. (17470OSI8)
A new install could fail under the following conditions. (1) The customer chose a different
directory other than the default directory for installing the PI Archives. (2) An archive with
one of the default names already existed in the target archive directory. This situation can
occur if a customer is moving their PI Server, or if the customer is migrating from the 32-bit to
the 64-bit PI Server. This problem has been fixed. (17375OSI8)
If the initial installation of the x64 PI server was done with manual PI Services, a subsequent
upgrade of the PI Server with automatic services selected would cause the PI Services to be
broken. This is because the registry value defining the services as automatic or manual would
be deleted. This problem has been fixed. (17342OSI8)
When the 32-bit PI Server was uninstalled on Vista or Windows Server 2008 (W2K8), the
following PI Services would not be completely removed until the next reboot: (1) PI
Performance Equation Scheduler, (2) PI Ramp Soak Simulator (rmp_sk) Interface, and (3) PI
Random Simulator (random) Interface. Entries for these services would still be visible in the
services control panel, but the description for these services would say "<Failed to Read
Description. Error Code: 2 >." One would need to do a reboot to complete the uninstall, even
though the uninstall was not guaranteed to prompt for a reboot. This problem has been fixed.
(17210OSI8)
When the 64-bit or 32-bit PI Server was uninstalled/upgraded on Vista or Windows Server
2008 (w2k80), the setup kit would fail to detect running PI Services. Although the PI Server
would not be automatically stopped, a dialog would prompt you to stop the PI Services that
were running. This problem has been fixed. (17209OSI8)
The serial number in the PI Server Setup/User Information Dialog has been removed. OSIsoft
originally planned to use the serial number as a license key, but this plan was abandoned.
Licensing is enforced via the pilicense.dat file. (17119OSI8)
PI would sometimes fail to start the first time that it was started on a cluster. The following
error would appear in the PI Message Log: "License confirmation Error: [-12208] user
mismatch". This problem has been fixed. (18404OSI8)
Page 24
The PIRESTOREDIR environment variable was not being removed when the PI Server was
uninstalled. This problem is fixed. (16607OSI8)
After uninstalling the 64-bit PI Server, subsequent installations of the 64-bit PI Server, the 32-
bit PI-SDK, and the 64-bit PI-SDK could fail. The 64-bit PI Server installation would fail because
it would detect that a 32-bit PI Server was already installed. The PI-SDK installations would
fail because they would detect that a PI Server was already installed. The cause of this problem
was that the "SOFTWARE\\Wow6432Node\\PISystem\\PI" registry key was not guaranteed
to be removed when the 64-bit PI Server was uninstalled. This problem has been fixed.
Uninstalling the 64-bit PI Server should now always remove this registry key. (19580OSI8)
When the 64-bit PI-SDK is installed on a PI Server node, the 64-bit PI-SDK would not be
removed when either the 64-bit PI Server or the 32-bit PI Server was uninstalled. This
problem has been fixed for the 64-bit PI Server kit. When the 64-bit PI Server is uninstalled,
the 64-bit PI-SDK will be uninstalled as well. If the 64-bit PI-SDK is installed on the same node
as the 32-bit PI Server, uninstalling the 32-bit PI Server will still not remove the 64-bit PI-SDK.
(18507OSI8)
The 64-bit PI Server setup kit was not assigning Everyone full permissions in the
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\PISystem registry key. As a result, only
an Administrator could use the PI-SDK on a 64-bit PI Server node. When a non-administrator
tried to use the PI-SDK, the AboutPI-SDK.exe and the connection manager would fail to launch.
This problem has been fixed. (18426OSI8)
If ping basic, snmp basic, perfmon basic, or the interface status utility were running, the pi
server installation kit would think that the PI Server was still running even though the other
services had been stopped. This would cause the installation to fail. This problem has been
fixed. (17654OSI8)
For the x64 installation kit, customers could accidentally configure the same directory for the
32-bit and 64-bit PIPC directories. The x64 bit PI Server now explicitly prevents this.
(12190OSI8)
The 32-bit PI Server would not start after upgrading the PI Server on Vista or Windows Server
2008. The following errors would occur when running the pisrvstart.bat command: "The
service name is invalid" and "System error 1075 has occurred." Certain PI Services would be
completely missing from the services control panel. Some PI Services would be present in the
control panel, but you would see the following error for the service description: "<Failed to
Read Description. Error Code: 2> ." This problem has been fixed. (12727OSI8)
If version 3.4.375.80 or greater of the 64-bit PI Server installation kit is installed, the 32-bit
installation kit will now detect that the 64-bit PI Server is installed and will terminate the
installation. If versions of the 64-bit installation kit prior to 3.4.375.80 are installed, the 32-bit
installation kit will still not detect the 64-bit installation kit is installed. So, the problem is
fixed only for upgrades starting with the 3.4.375.80 64-bit installation kit. (17468OSI8)
Page 25
Enhancement
The 32-bit PI Server installation kit will now terminate if one tries to install it on an x64
machine and if the operating system is Windows Server 2008 or greater. This combination is
disallowed because Microsoft no longer supports 32-bit VSS Requestors and 32-bit VSS writers
on x64 machines starting with Windows Server 2008. In other words, VSS backups would not
work if OSIsoft allowed the 32-bit PI Server to be installed on an x64 machine beginning with
Windows Server 2008. Note, however, one can still install the 32-bit PI Server on x64 Windows
Server 2003. (17477OSI8)
When the PI Server is uninstalled, pisetup.exe and piins32.dll are now removed from the
\PI\setup directory. (16483OSI8)
Security options for explicit logins can now be configured in the setup kit. These options are
(1) to disable all explicit logins, (2) to disable all explicit logins with blank passwords, and (3)
to disable all explicit logins for the piadmin account. For upgrades, if piadmin logins are not
disabled with option (1) or (3) and if the piadmin password is blank, you will be prompted to
enter a password for the piadmin account, but you will not be forced to enter a non-blank
password. For new installations, if explicit logins are not disabled for piadmin, entering a non-
blank password for piadmin is now mandatory. (16953OSI8)
If any system digital states are missing when the PI Server is upgraded, the installation kit will
now add the additional digital states. Also, if a digital state conflict is detected during the
upgrade, a popup dialog will be displayed with the text: "Warning! Some states in the system
digital state table cannot be updated because user-defined states exist at the same indices. This
is only a warning." The message box will also display the particular digital states that are in
conflict. (17600OSI8)
Informational
For all new PI server installations, the default installation directory is now "c:\Program
Files\PI" (or "c:\Program Files (x86)\PI" for the 32-bit installation on x64 Windows). This is
only a default. Customers can still choose to install the PI server elsewhere, such as under
c:\PI, d:\PI, etc. The default installation directory was changed for Windows 2008 certification.
(17472OSI8)
For new installs, the default event queue size is now 128 MB and the default archive file size is
now 256 MB. (16269OSI8)
When upgrading a collective, the setup kit now requires the primary PI Server node to be
upgraded before the secondary PI Server nodes. If a secondary is upgraded before the
primary, setup will terminate with a message similar to "The installation cannot proceed.
Error, the version of the primary PI Server was detected to be 3.4.375.xx. You must upgrade
the primary before upgrading the secondary." If for some reason you must upgrade the
Page 26
secondary node before upgrading the primary node, please contact OSIsoft Technical Support
for the procedure. However, it is recommended to upgrade the primary node first so that at
least one PI Server can remain online during the PI Server upgrade. After upgrading a
secondary PI Server from 3.4.375 to 3.4.380 or greater, the secondary PI Server will not be
available until the primary PI Server is upgraded and the secondary is re-initialized from the
upgraded primary. (20472OSI8)
Internals
Enhancement
At startup, if one subsystem was waiting on another subsystem for a long time, it was difficult
to know what was happening. Now, at startup, if one subsystem is waiting for another
subsystem for longer than two minutes, a message is printed every two minutes. (19046OSI8)
License
Enhancement
For node-locked licenses, if there was a mismatch between the pilicense.dat file and the server
node, a message would be written to the PI Message Log indicating that a
MachineMismatch.Report file has been generated. In 3.4.375 and earlier, the
MachineMismatch.Report would be written to the \windows\system32 directory (provided
that pilicmgr.exe was running as a service). In 3.4.380, the MachineMismatch.Report is now
written to the \pi\dat folder to make it easier to locate for customers and OSIsoft technical
support. (17281OSI8)
In 3.4.375 and earlier, after the PI License Manager had started and had read the pilicense.dat
file successfully at least once, license manager would shut down if it subsequently failed to
read the pilicense.dat file 3 consecutive times. In 3.4.380, the PI License Manager still checks
every 5 minutes for new license information in case a new pilicense.dat file is copied to the
machine. However, license manager will no longer shut down due to failures to read the
pilicense.dat file, provided that license manager has read the pilicense.dat file successfully at
least once. The license manager will now continue to run using the license information it has
currently loaded. (15163OSI8)
The enforcement level of each license entry in the license file is now displayed by piartool -lic
def. (18035OSI8)
Manual
Defect
SQCAlarmPS was incorrectly named in the PI Server Application User Guide. This will be fixed
for the version 3.4.380 of “PI Server Applications User Guide”. (16334OSI8)
Page 27
The PI Totalizer manual instructs to use /c (short for /utc) for Period attribute. This is
incorrect, it should instruct to use /u instead of /c. This will be fixed for the version 3.4.380 of
“PI Server Applications User Guide”. (15621OSI8)
Message
Defect
Messages in the Windows Event Log from “crypt32” can get written to the PI message log file.
The issue was that some of the Event IDs that the PI Server uses are shared by crypt32, a
Microsoft application. (18252OSI8)
Writing messages from the Windows Event Log to PI can take a long time. On Windows, when
the PI Message Subsystem (PImsgss) is not running, messages written by PI clients are
redirected to the Windows Event Log. When PImsgss starts up it reads these messages and
inserts them into the PI Message Log. When there are a lot of these messages, the PI Message
Subsystem can become unavailable for reading or writing messages, potentially generating a
vicious cycle. PImsgss 3.4.380 throttles the processing of messages from the NT event log in
order to mitigate this issue. (11342OSI8)
Module Database
Defect
Read access to PIModules token in the DBsecurity table, now implies also read access to the
PIHeadingSets token. This is to allow operations on modules that require read access to
heading sets. (19401OSI8)
NetMgr
Defect
In some situations PI Network Manager (PInetmgr) could have crashed if it was unable to
acquire resources to remove an API connection, but there were outstanding requests for data
that later get answered. These further responses were not handled properly by PInetmgr and
could have caused it to crash. This scenario was not common, but it had been found to occur in
networks where connection drops were common, and very busy API applications were being
used. This issue has been fixed. (18695OSI8)
PI Network Manager had a memory leak which was encountered if 10,240 simultaneous
connections were exceeded. This issue has been resolved. (2363OSI8)
On slow networks, or networks with high latency, PI Network Manager (PInetmgr) would
occasionally complain about being unable to obtain a lock on a connection, accompanied by a [-
16214] error. This was a serious problem if PInetmgr was busy sending information from one
Page 28
connection to another; PInetmgr would be unable to perform activities on either connection.
Affected subsystems would not be responsive while the operation was in progress. The
affected subsystem would only be reachable again if the offending client connection was
disconnected.
This error commonly occurred in conjunction with PLI 13660OSI8, where updating all client
connections with the RPC table would delay several other activities, especially new
connections.
The entire connection management strategy in PInetmgr has been changed for 3.4.380. If a -
16214 error is returned in PInetmgr in version 3.4.380 with regards to a connection, this
simply indicates a very busy system, and the error should go away within a few seconds.
(9604)
When there are multiple applications associated with a particular connection, there will be
multiple connection accepted messages with the same connection ID. This is most likely to
occur with connections from Excel because TagConfigurator, Datalink, BatchView, AF, etc., all
identify themselves as a particular application from the same connection. This has been fixed.
(11328OSI8)
Enhancement
One of the most common problems in PI Network Manager (PInetmgr) is the delay of activities
related to executing a reverse name lookup call on a machine where this operation is slow or
unavailable. In version 3.4.380, all reverse name lookup activities are disabled by default,
except in the case of API clients connecting to the server, where this information is needed for
trust authentication. PInetmgr will only perform the reverse name lookup for messaging and in
the PI Network Manager statistics if the new timeout table parameter "DoRDNSForMessaging"
is set to 1. (20935OSI8)
Unauthenticated PI-API connections no longer have valid security on the PI server in 3.4.380.
This is in contrast to previous versions of the server, where the DefaultUserAccess timeout
table setting would allow unauthenticated users access to the server. This setting is no longer
supported in 3.4.380. To prevent data loss due to mis-configuration of a PI Trust, PI Network
Manager will disconnect unauthenticated PI-API connections after a certain period of time. The
tuning parameter: PInetmgr_UnauthAPITimeout controls this behavior. The default setting is
120 seconds, but it can be set anywhere from 0 (disabled) to 3600 seconds. (19962OSI8)
In server versions 3.4.375 and earlier, PI Network Statistics would show the OS user, name of
the trust, and PI user that were last active or attempted on a particular connection.
Applications such as PI WebParts serve many different users at the same time on one
connection to the PI server. PI Network Manager now reports a list of all security contexts that
are authenticated on one connection. This functionality is present in PICONFIG, and the version
of SMT3 that ships with the 3.4.380 server. (18722OSI8)
PI Network Manager (PInetmgr) can now execute the following tasks in parallel:
1. Cleaning up dead connections
Page 29
2. Checking the health of PISDK or native pinet3 connections
3. Checking to see if an API connection needs to be timed out
4. Seeing if any call made to a subsystem being performed by PInetmgr itself has timed out
5. Updating the registration of subsystems
6. License manager tasks
7. Firewall table refresh
8. Accepting and processing a new connection
These changes mean that PInetmgr will be more resilient to delays in any of the
aforementioned tasks, and respond faster to new connections as a result. (13660OSI8)
PI Network Manager now supports a maximum of 32767 connections. (13229OSI8)
PI Network Manager now logs an error to the message log when a failure occurs in obtaining
credentials. The message looks like the following:
"Unsuccessful login ID: [connection ID]. Address: [IP address]. Name: [Host name (optional)].
Credentials used: [Authentication credentials obtained]. Method: [Authentication method
used]. Status: [error status]".
This type of messaging is helpful in order to understand what is happening when
authentication fails. (19494OSI8)
Security
Enhancement
Feature request: Login Security Improvements
1. Log failed login attempts
2. Insert delays on failed login attempts
3. Enforce password minimums
4. Enforce password timeouts
With the possible exception of item #2, these features are supported by Windows Integrated
Security, as delivered with PI Server 3.4.380. (5120OSI8)
Added dynamic tracing to PIIdentityMappingTable::Authenticate to gain insight into results of

Identity Mappings. Main purpose is troubleshooting in production environments with release
code. Tracing is disabled by default. See the descriptions of the timeout table entries
Base_SIDTraceCheckMinutes and Base_SIDTraceTimeoutMinutes for details on how to use this
feature. (20473OSI8)
Previously, only the piadmin PI User could modify Batch Subsystem (BSS) configuration (units,
aliases) and batch data. Access can now be delegated via a new DBSecurity entry called
PIBATCHLEGACY. (5532OSI8)
Page 30
Previously, only the piadmin PI User could override another user's password (if that user
forgot the password, for example). This privilege has now been extended to any member of
the piadmins PI Group. (9621OSI8)
Previously, when creating a trust with IPAddr and Netmask, the relationship (IPAddr &
Netmask) == IPAddr had to be true. Otherwise, the error "[-10411] Security or trust relation
mismatch" was returned. This condition has now been relaxed, allowing you to create a trust
with IPAddr = 10.10.10.109 and Netmask = 255.255.255.0, for example. (20124OSI8)
Previously, only the piadmin PI User could modify the PIDBSEC DBSecurity entry. This has
been enhanced to allow any member of the piadmins PI Group to modify PIDBSEC.
(19836OSI8)
Previously, only the piadmin PI User could modify point classes and attribute sets. This
privilege has been extended to any member of the piadmins PI Group. (19835OSI8)
Previously, only the piadmin PI User could delete connections. This privilege has been
extended to any member of the piadmins PI Group. (19834OSI8)
Previously, if a client application passed any of the security attributes during a point edit, the
PI Base Subsystem would always consider that a change (even if the values were the same),
and thus always perform a security check. The logic within PI Base Subsystem has been
enhanced so that a security check is only performed when the values of security attributes are
actually changing. (2281OSI8)
Through the use of PI Mappings, PI Servers can now be configured to allow PI logins based on
Windows domain username. These features are supported by Windows Integrated Security, as
delivered with PI Server 3.4.380. All authentication is handled by Windows (either Active
Directory or local security). Access control lists have been implemented internally and provide
functionality similar to that of Windows security descriptors. (1397OSI8)
Session
Defect
A subsystem does not handle the errors that result from sending very large messages to PI
Network Manager. The message send action consumes lots of resources within Windows, and
is unable to recover from this situation. In this case, the data stream from the subsystem is
stalled, and may not recover. This is not applicable to x64 versions of the PI server. This has
been fixed. (6279OSI8)
Page 31
Snap
Defect
When the Buffer Subsystem was connected had no permission to write to a point (Data
Security), one snapshot value would still be written until all value would be blocked with
errors “[-10401 No Write Access – Secure Object”. This initial snapshot event is a defect and
should not be allowed. This issue is now fixed against the PI Server version 3.4.380 and above.
(18396OSI8)
Under very specific and rare circumstances, the Snapshot Subsystem would temporarily hang
when it received a string event for a point with a point type other than String or Blob. The
Snapshot Subsystem would be unresponsive for some multiple of 30 seconds before resuming
normal operation. The Snapshot Subsystem was only vulnerable to this issue if the Snapshot
Subsystem performance counter "Digital State Translations/sec" was nonzero and a digital tag
had been added/edited since the Snapshot Subsystem was last started. This issue has been
resolved. (18358OSI8)
The PI Server 3.4.380 has a minimum support requirement for the Buffer Subsystem (pibufss)
of version 3.4.375.84 (PR1 SP1). When connected to 3.4.380, the buffer subsystem no longer
perform security access checks, since they are performed by the Snapshot Subsystem on the
server side. Snapshot audit records will contain the correct User, Group or Identity ID that the
Buffer Subsystem is running under. A defect in 3.4.375.x PI Servers could make the User ID
appear as "-1" within Snapshot audit records generate by events received from pibufss. This
issue is now fixed.
IMPORTANT: pibufss 3.4.375.38 is NOT supported against 3.4.380 PI Servers and will fail to
process and send data. An upgrade to pibufss 3.4.375.84 or later is required. (19757OSI8)
Until release 3.4.380, the span attribute of digital points was used to signify the size of the
associated digital set (number of states - 1). This number was used by the snapshot subsystem
to validate incoming events. This required an implicit point edit in the Base Subsystem
whenever a digital set was changed. Since these edits occurred asynchronously, there were
several situations where the snapshot subsystem was out of sync with the digital point
configuration and temporarily reject new data. Changes to the size of digital sets were not
reflected in the associated snapshot records until these points were actually accessed for
viewing.
This inconsistency is now resolved. Both the Snapshot and Archive Subsystems refer directly
to their digital state table cache to determine the size of sets. Also, this cache is updated in real-
time as opposed to only once a minute. (17722OSI8)
Enhancement
PIBASESS –SNAPFIX has been enhance in the following ways:
Page 32
1. Always check for points with duplicate recnos. If found, these points are listed in the
output. Recovering from this issue requires careful selection of the point to recover. Please
contact our technical support team for assistance.
2. PIDIAG -PTPURGE is incorporated as PIBASESS -SNAPFIX -PTPURGE <argument>

<argument> can be a single tag name or a text file including a list of tags.
This can be used to remove points with duplicate recno found in #1 above.
3. -FILE <filename> can be specified as an alternative input file, instead of piarcmem.dat

from the PI\dat.
4. -DS <state> can be specified to select which system digital state will be inserted in a newly
created snapshot file, or for substituted snapshot records. By default this will be the state
"snapfix" (System Digital Set, offset 316).
5. -MAXTIME <time> can be specified to define a time limit. Snapshot values that has a time
greater than the limit are removed and replaced with "snapfix" state (or whatever was
specified in #4) at current time. The default limit is 10 minutes in the future of run time.
PIbasess -snapfix checks for the existence of the snapshot file (piarcmem.dat). If the file
exists, a backup copy is created with the current time stamp in its name. For instance,
“16_Mar_09_17_31_04piarcmem.dat”.
The Digital state inserted during PIBASESS -SNAPFIX is transient and is replaced during
runtime by the first snapshot value with a timestamp greater or equal to it. In other words,
that value does not go to the archive.
(3159OSI8)
SQL
Defect
When specifying IPISQL -O EXECSAFE,<subset>, the result is:

ROWS,0,ERROR,15,[15] The system cannot find the drive specified.
instead a subset of result. (13906OSI8)
Any number of tag with names longer than 1016 characters caused the SQL Subsystem to fail
preparing queries with the error [-251] Memory allocation error. This is now fixed.
However, note that the maximum length of tag name is still 1016. If the tagname exceeds
1016, the behavior reverts to what PLI 3356OSI8 describes:
When a join involves tags that are more than 1016 characters, the result is not correct. It
will return no row found. If there is no join, rows are returned, but the tag name will be
truncated to 1016 characters. (11367OSI8)
Page 33
The IPISQL utility reports “Error [-268] Syntax error” when executing a query that exceeds the
processing limit (IPISQL -O EXECSAFE). The appropriate error message is now:
[-268] SQL: execution too expensive
(13907OSI8)
Totalizer
Defect
Previously, the PI Alarm Subsystem and PI Totalizer Subsystem would sometimes report
"listpt failed" messages for tags that were not alarm or total tags, respectively. This usually
happened when large numbers of points were renamed or deleted. This issue has been fixed.
(2015OSI8)
UpdMgr
Defect
The batch update producers PIBatchUpdates, PICampaignUpdates, PITransferRecordUpdates,

and PIUnitBatchOnUnitUpdates did not enforce security when authorizing batch update
signups. This issue has been resolved. To signup for updates on the PIBatchUpdates,
PICampaignUpdates, PITransferRecordUpdates, and PIUnitBatchOnUnitUpdates update
producers, the client application will now require read access to the corresponding batch
storage point. (19601OSI8)
Enhancement
The Update Manager consumer statistics summary, PILISTUPD -CS, now includes the Network
Manager connection ID for each consumer under the column heading ConnectID. The
consumer ConnectID is the same as the ConnectID reported by Network Manager Statistics and
can be used to identify connection statistics for a specific consumer. If a persisted consumer is
not running when the Update Manager is started, the ConnectID will be -1 until the consumer
re-registers with the Update Manager. (9799OSI8)
Informational
Signups for point updates on a Point Source was included starting in PI 3.4.370.52. This
functionality has never been exposed through the PI SDK. This functionality was exposed
through the PI API starting with version 1.4.0.2 by the function pipt_signupforupdatesfil.
However, OSIsoft products have never used this functionality because it was not fully
functional. The PI API pipt_signupforupdatesfil function now returns "[-10008] Unsupported
or Unimplemented Call" until the feature is added back. (19484OSI8)
Page 34
Utilities
Defect
If the SQL parameter is not supplied by the command argument in IPISQL, it is prompted
interactively. If the value is surrounded with quotes it is not processed correctly. This issue is
now fixed.
Example:
select * from piavg where time >= 't' and time <= '*' and tag=?
Enter "?" at the prompt for help
Enter a value for ? [0]: "sinusoid"
Executing SQL statement...FAILED, Error [-257]

Tag < sinusoidd > not found
(13668OSI8)
If a backup failed, the backup log (pibackup_dd-MMM-yy_hh.mm.ss.txt) would sometimes

report that the "pibackup.bat script completed successfully" at the end of the log file. The
PIARTOOL -BACKUP command now returns an error code so that failed backups are reported
appropriately at the end of the log. For example, a failed backup message similar to
"pibackup.bat script failed with error -16919" should now appear at the end of the log file.
(19877OSI8)
For PIARTOOL -UPD, the producer name had to specified using the same case as the producer
name registered with the Update Manager. This issue has been resolved. For PIARTOOL -UPD,
the producer name is no longer case sensitive. (19754OSI8)
Under some circumstances the PIARTOOL -BLOCK command would block for longer than the
maximum wait time if the specified subsystem was unresponsive. This was especially
problematic for wait times less than 30 seconds. This issue has been resolved. The PIARTOOL -
BLOCK command will always respect the maximum wait time even if the subsystem is
unresponsive. (18908OSI8)
PIDIAG -CPC can report multiple messages of the type "Manual: Registry entry... may be
corrupt". If present, this error is now generated once. (20058OSI8)
PIARTOOL -OOO -REMOTE on a PI Client or Interface Node (PINS node) was misleading and
returned "no out of order events found". It now returns "Error [-10727] PINET: RPC is Non-
Existent." (20199OSI8)
Page 35
PIDIAG -ADG does not return any error with archive file that does not exist. This is not
corrected. (20216OSI8)
Enhancement
The PIARTOOL -UPD command had been enhanced to provide statistics for every update
producer. Previously this command only provided accurate statistics for the snapshots, archive
and ptupdates update producers. The PIARTOOL -UPD command now reports whether the
producer is registered with the Update Manager (Registered), the return status from the last
time events were sent to the Update Manager (Send Status), the state of the update buffers
(Buffer Status), the number of updates in each update buffer (Buffer 1 Count, Buffer 2 Count),
and the current update buffer (Current Buffer). The Unsent field has been renamed Pending
Count. As before, the Total Signups field reports the number of individual records with update
signups. The new Global Signup field indicates whether there is a signup on the entire table.
Individual signups are no longer reported by default. If the producer supports record-level
signups, individual signups can be listed using the new -LS argument. (13219OSI8)
The PIARTOOL -BLOCK command has been extended to support chained blocks. The chained
block is useful for troubleshooting and can be used to confirm that one subsystem can
communicate with another subsystem via an RPC. The chained block behaves as follows. If the
first subsystem is responsive, the first subsystem will block against the second subsystem. The
chained PIARTOOL -BLOCK command will block until the chained block returns or the
maximum wait time is exceeded. The chained PIARTOOL -BLOCK will report the time and the
success/failure of each block. The syntax for the chained block is: PIARTOOL -BLOCK
<SUBSYSTEM1>,<SUBSYSTEM2>. For example, "piartool -block pisnapss,piarchss -verbose"
will report whether piartool can communicate with the Snapshot Subsystem and whether the
Snapshot Subsystem can communicate with the Archive Subsystem. (19033OSI8)
The PIARTOOL -BLOCK command has a new -RPCTIMEOUT argument. If this argument is used,
the maximum wait time will be used explicitly for the RPC timeout. This behavior is useful for
troubleshooting. (19035OSI8)
Several minor enhancements to PICONFIG tables:
1) Made piserver and picollectve top level tables, for example typing
"@table piserver" is now equivalent to "@table pisys,piserver"
2) Made pitimeout and pifirewall top level tables
3) Added piidentity, piidmapping tables
4) Hid the pigt, pisys and pigen top level tables, however they are still present.
5) Display the tables in alphabetical order when listing all tables.
(18414OSI8)
Page 36
The PIDIAG was enhanced to prevent unintended changes to files from older versions, and
offer new tools to inspect files. The following enhancements were done:
-FB opens the file readonly. (-DV optional switch to display the filebase version only.)
-FBF requires an output file (this was optional) and the input file is opened in read-only
-FBF and -FBC would not operate on files with major version < 4 (the 3.4.380 version) to
assure that security settings are converted using the 380 setup program. PIDIAG issues a
warning when opening file of the old format.
-FB, -FBF and -FBC have an optional switch -HEADER to suppress index display and show
only the header. This can be useful for very large files. (19972OSI8)
When running PIDIAG -FBF, the error "[-10466] No Record Available for Passed recno" may be
returned numerous times. This is expected and does not indicate any corruption with the file.
PIDIAG -FBF no longer reports these -10466 errors when they're expected. (17207OSI8)
If PIDIAG -T was used with a numeric time input where the first digit was not zero, the
following error was reported: "Invalid time string for translation". This leading zero
requirement has now been removed except when the numeric time input is ambiguous (e.g.
day of month); in such cases, relative time conversion will be performed unless a leading zero
is used. (8759OSI8)
PI Server collectives on clustered nodes: new PIDIAG commands -ecert and -icert
-ecert : export the server's certificate from the certificate store to a file.
-icert : import a certificate file into the server's certificate store.
In 380 collectives use public/private keys to do authentication among collective members.

The primary create a certificate with this information, and the secondary servers use the public
key to connect back to the primary. The issue on a cluster is that the two members of a cluster
each have separate certificate stores that need to be initialized. These commands enable PI
administrators to move a certificate from one cluster member to another. Please refer to the “PI
Server Installation and Upgrade Guide” for more details on how to use these commands.
(19847OSI8)
Page 37
Technical Support and Resources
OSIsoft provides dedicated technical support internationally, 24 hours a day, 7 days a week to
customers with a current SRP contract. To locate local access numbers and current contact
options, please visit our Contact Methods page on the Technical Support web site at
http://techsupport.osisoft.com. The main contact information is also listed below:
Telephone: +1 510 297-5828
E-mail: techsupport@osisoft.com
Web Portal: My Calls
When you open a case using any of the above methods, you will receive a response from a
Technical Support Engineer within four hours. Be sure to provide:
Product name, version, and/or build numbers
Computer platform (CPU type, operating system, and version number)
The time that the difficulty started
The message log(s) at that time
You can also take advantage of the Self-service Search page on our Technical Support Web
Site to look for answers to your technical questions and issues. The search tool searches our
online library of documentation, knowledge base articles, technical announcements and
bulletins, known product issues, and documented product enhancement requests, as well as a
collection of resources for system managers.
Page 38
OSIsoft, Inc. OSIsoft Australia
777 Davis St., Suite 250 Perth, Australia
San Leandro, CA 94577 USA Auckland, New Zealand
(01) 510-297-5800 (main phone) OSI Software GmbH
(01) 510-357-8136 (fax)
(01) 510-297-5828 (support phone) Altenstadt, Germany
http://techsupport.osisoft.com OSI Software Asia Pte Ltd.
techsupport@osisoft.com Singapore
Houston, TX OSIsoft Canada ULC
Johnson City, TN
Longview, TX Montreal, Canada
Mayfield Heights, OH OSIsoft, Inc. Representative Office
Philadelphia, PA
Shanghai, People’s Republic of China
Phoenix, AZ
Savannah, GA OSIsoft Japan KK
Seattle, WA
Tokyo, Japan
Yardley, PA
OSIsoft Mexico S. De R.L. De C.V.
Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda.
Sao Paulo, Brazil
Sales Outlets/Distributors
Middle East/North Africa South America/Caribbean
Republic of South Africa Southeast Asia
Russia/Central Asia South Korea Taiwan
www.osisoft.com
OSIsoft, Inc. is the owner of the following trademarks and registered trademarks: PI System, PI ProcessBook, Sequencia,
Sigmafine, gRecipe, sRecipe, and RLINK. All terms mentioned in this book that are known to be trademarks or service marks
have been appropriately capitalized. Any trademark that appears in this book that is not owned by OSIsoft, Inc. is the property of
its owner and use herein in no way indicates an endorsement, recommendation, or warranty of such party's products or any
affiliation with such party of any kind.
RESTRICTED RIGHTS LEGEND

Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013
Page 39

PI3ReleaseNotes 3.4.380.36

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

PI3ReleaseNotes 3.4.380.36

Hochgeladen von

Copyright:

Verfügbare Formate

PI Server 3.4.

380 – Windows Integrated Security

PI Server Version 3.4.380.36

Setup Program—Secure configuration by default, with database consistency

Supported Operating Systems

Windows 2000, SP4 (x86)

Windows XP, SP2 and above (x86, x64)

Hardware Virtualization Support

Known Issues with Windows Server 2008/Vista

Known Issues with Windows Server 2008 R2 Core

3. Run setup.exe from the extracted files.

Known Issues with Performance Counters

Installation and Upgrade

Upgrading PI Server Collectives

The PI Server 3.4.380 introduces fundamental changes to the PI security model. As a

1. Upgrade the Primary and validate functionality;

Installing and Uninstalling on Windows Server Core

2. Run setup.exe from the extracted files.

Silent Installation or Upgrade

When PI AutoPointSync is installed on a 64-bit version of Windows, the PI APS

WORKAROUND: PIAPSSyncTrigger.exe version 2.0.3.0 is available for download as a

In an HA collective, on a Secondary, with auditing enabled, the Snapshot and Archive

List of Products Installed During Setup

Product Software Version

Microsoft Visual C++ Version 8.0.50727.762

Microsoft ATL Version 8.0.50727.762

Product Software Version Installation Kit Version

PI Server 3.4.380.36 3.4.380.36

Product Software Version Installation Kit Version

PI Server 3.4.380.36 3.4.380.36

When performing offline archive reprocessing of an "auto-dynamic" archive, the contents of

If the tuning parameter Archive_MaxWriteCachePerPoint was set to a value of 0, the Archive

The -INSTALL flag for pibackup.bat is no longer case sensitive. (17942OSI8)

Incremental backups are now available in 3.4.380. Previously, in 3.4.375, a form of

PIBATCHLEGACY - Control access to configuration/viewing of the old batch system. Previously

The timeout parameter "WindowsAuthentication" has been renamed to

Incorrect output with 2 sub-second decimals:

The Collect Procedure for the "X" service in DLL "d:\program

Faulting application pinetmgr.exe, version 3.4.375.38, faulting module

Starting in PI 3.4.380, PI HA Collectives use a certificate-based authentication mechanism

When the OSIsoft MS Runtime Redistributables (MSRuntimes.msi and MSRuntimes_X64.msi)

PI Network Manager now supports a maximum of 32767 connections. (13229OSI8)

Feature request: Login Security Improvements

1. Log failed login attempts

2. Insert delays on failed login attempts

3. Enforce password minimums

4. Enforce password timeouts

Added dynamic tracing to PIIdentityMappingTable::Authenticate to gain insight into results of

PIBASESS –SNAPFIX has been enhance in the following ways:

2. PIDIAG -PTPURGE is incorporated as PIBASESS -SNAPFIX -PTPURGE <argument>

3. -FILE <filename> can be specified as an alternative input file, instead of piarcmem.dat

When specifying IPISQL -O EXECSAFE,<subset>, the result is:

[-268] SQL: execution too expensive

The batch update producers PIBatchUpdates, PICampaignUpdates, PITransferRecordUpdates,

Executing SQL statement...FAILED, Error [-257]

If a backup failed, the backup log (pibackup_dd-MMM-yy_hh.mm.ss.txt) would sometimes

Several minor enhancements to PICONFIG tables:

2) Made pitimeout and pifirewall top level tables

3) Added piidentity, piidmapping tables

5) Display the tables in alphabetical order when listing all tables.

-icert : import a certificate file into the server's certificate store.

In 380 collectives use public/private keys to do authentication among collective members.

RESTRICTED RIGHTS LEGEND