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 would like to be able to order by name (alphanumerically) the Analysis in the Management tab in PI System Explorer after retrieving a list of analyses through a search/filtering. This could be done by clicking on the Name column.

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). 

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.

It is possible to name these files more specifically to convey what to expect when running them:
Example 1: AFSQL295.bat
Example 2: AFSQL290.bat
Example 3: VisionSQL320.bat

Currently a single name of Go.bat is assigned to SQL management scripts associated with many products with many versions.

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.

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.

On the AF server we have things structured in different databases. When working in a database it would be great if I could use a database template (e.g. element template) from a different database. In some cases these templates are valid for both databases and I don't want to copy them when they are changed.

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.

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

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.

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.

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.