On high latency networks, it can take ICU many minutes to start because every interface on the PI Data Archive is checked. Minimize startup time by caching a node's registered interfaces.

I want the ability to track if auditing was turned off for the PI System (PI Data Archive and AF) so that I can determine if there was the risk of potential changes that were not captured by PI System audit functions.

I can be helpful when tracking down issues or troubleshooting past events what the values of tuning parameters were at a given time. Adding the ability to Audit this table would allow retrospective insight into tuning parameter configurations.

A similar enhancement specifically regarding Auditing can be found here:
https://feedback.osisoft.com/forums/555148-pi-server/suggestions/18740068-track-if-auditing-was-turned-off

I want the ability to determine what PI System Configuration Changes (AF & PI Data Archive) are legitimate and approved, with the criteria of being able to focus on changes that occurred during a user defined time range. I want to minimize the time it takes to confirm that changes were appropriate with the ability to focus on certain tags/af attributes and/or time for the change.

I want the ability to associate a change control record to PI System Configuration Changes.

As a PI Administrator with a test PI Server, I need to be able to easily promote configurations from our test environment to our production environment. Currently this is extremely difficult and a very manual process.

We have hundreds of mappings/trusts in SMT and there's no way to search them (apart from exporting it all to Excel, and searching there, then going back to SMT to make necessary changes - not user friendly). There needs to be a basic search bar at the top of that panel, and it should search all fields (except server and collective) in whatever tab has focus (mappings or trusts). 

When backfilling historical data, piarchss logs messages like this one:
Inserting overflow record 4035947. Point: 41455, archive start: 4-Jan-17 20:34:10, first event time: 25-Jan-17 09:49:00, record event count: 100, overflow count: 98

When a large amount of data is backfilled, the large number of such messages makes searching more difficult and may alter performance.

It would be useful to be able to determine when (or even if) a PI Point was last accessed by a client application to retrieve its data.  This would enable redundant points to be identified and removed.

Alternatively/additionally some form of access tracing such as used to be provided by the AAG tool would be useful to determine which clients access which points.

Currently, only common tuning parameters are visible by default in PI System Management Tools. Somewhere, whether in PI System Management Tools or online, there should be a list of ALL tuning parameters with their description, subsystem, minimum value, maximum value, and default value.

This would let PI administrators set the tuning parameters proactively rather than reactively. Instead of the PI administrator needing to think "might this tuning parameter exist?" or waiting for a problem to occur before learning about a tuning parameter, they just need to look through the master list.

An option to suppress "[-15011] PIvalue Type is Not Numeric" when there is a non-numeric OOO event (e.g. string or digital value) between the pibufss last compressed event and snapshot event. While these messages are only informational they can quickly fill up message logs.

Currently, if you delete a PI Identity that is still being used, the deletion will succeed and the PI Identity gets renamed to a number everywhere that it is used. This doesn't do much good, since the number does not reveal what the PI Identity used to be called, and if you regretted the deletion, you would have to create a new PI Identity and assign it permissions from scratch anyways. Instead of renaming, consider removing the deleted PI Identities.

Show the list of connectors(SMT->Interface List) along with the list of interfaces associated with the Data Archive.

Progress bar for SMT->Archive Editor when deleting large volume of data.

Currently, when deleting around 30,000 events it takes approx 20 mins and the GUI appears to hang and become unresponsive (it is actually working). A progress bar would alleviate this concern.

In the Point Builder, if the user makes a change to one tag and they click on a different tag, ask them if they want to save/discard changes.

The description for the MarkArchiveGaps tuning parameter for a value of 2 is unclear.

A user might interpret:
2 - Gap markers only when there is an actual gap between two consecutive archives.

to mean that markers are shown when a tag does not have a value for two consecutive archives. However, it means that markers are shown if a time/archive gap exists between two consecutive registered archives.