Before upgrading or migrating a PI Data Archive it is important to understand the health of the system (as a general rule, one should only upgrade/migrate a system that is healthy).
There are already many aspects of PI Data Archive health that you can check using this Powershell example.
The example mentioned above does not, however, cover PI Interfaces and Buffering, so I built another script to check those aspects of the system.
I also wanted this to be a Powershell script and not an application, so it is readable, changeable, and programmable on a platform available on basically any Windows machine (you don't need Visual Studio).
The PI interface configuration is stored in the Module Database, accessed programmatically via PI SDK. So one of the prerequisites of this script is PI SDK.
PI SDK is a legacy programming technology, so we will use it only to access the Module Database. For the rest of the script, we are going to use AF SDK, which is the recommended programming library. .NET Framework 4.5 is also a prerequisite.
At this point, it is important to remember that using PI SDK and AF SDK requires PSA license for production environments. It is also important to remember that this is just an example. It is not an official script. OSIsoft does not provide any specific support on this script. Despite that, the comment section on this page is available for discussion.
I'm assuming that you have the necessary permissions to run scripts, and administrator permissions on PI Data Archive via Mapping or Trust. Remember that your Script Execution Policy must be set to Unrestricted.
The script asks the user for the PI Data Archive name and returns the following table, containing the Interface name, the machine name where it is installed, the Point Source and Interface ID, the number of tags that match that Point Source and ID (except for UFL and Random, that show the tags that match only Point Source), as well as the last tag update for that interface for each PI Data Archive (it works for a collective of two members):
The table above allows us to understand the data collected by PI Interfaces. This is really useful when verifying the health of a system that you don't know much about yet. It is also possible to infer on buffering status by looking at the last tag update from both members of a collective (PIPing1 has different data on primary and secondary members, so the buffer is not working or turned off).
After that, a Buffering Sources table for each member is also printed, containing more info about buffering.
After running this script, we are able to identify the interface machines that we should access to check buffering, before proceeding with the upgrade/migration.
The script is attached to this post.
I hope this helps you!
Adding a new version to the zip folder. V2 also displays the Host and the Source Host interface parameters. It also fixes some bugs.