To take full advantage of AF and substitution parameters it would be great to have a sort of type ID. Now i have to rename all tags to gain this possibility. It would be easy if i could use a portion of the tag name and a  type id. Then i could deploy AF templates with substitution parameters really fast.

Customer would like to be able to loop future data.  For instance since yearly temperatures are about the same every year for a given month, it would be nice if only one set of the projections are stored somewhere and just repeated again and again every year.

It would be helpful to determine which users or applications made heavy requests to the Data Archive Server.
This could be an option to be activated or not.
Logging the ip, user identity, concerned tags, duration of the request
Those information are actually available in PI SMT but there is no way of storing and analyzing them.

Background:
On a Data Archive where many points have been deleted, there will be many unused record numbers. Since the size of an archive file is tied to the highest existing record number (for performance reasons), this can result in archive files that are much larger than necessary.

Request:
A method to eliminate unused record numbers, likely by modifying record numbers. As an example, three points with record numbers 1, 3, and 10 would turn into record numbers 1, 2, and 3.

As a Pi Admin, it would be usefull to be able to locate the Precommit directory used during the PI backup process to a different location from the Backup directory

The ability to define and rollout compression standards on tags across the enterprise / sites. 

When this information is captured bottom up from sites, bad settings make it difficult to maintain a standard which inhibits cross site data comparisons.

Currently, if you want to store predictions for 1 day, 2 days, 3 days, etc. into the future, you must create a different PI tag for each distance into the future.

Future data tags should support 2 timestamps: the timestamp that the predicted value applies to and the timestamp of when the prediction was made.

The additional continuous time dimension will make it much easier to analyze the change in accuracy of prediction as the distance into the future changes.

Currently, the Data Archive stores the timestamp of an event as well as it's value. It would be useful to also store the timestamp at which the event arrives at the Data Archive (perhaps this could be a configurable option set for individual tags). This would be very useful for example in situations where events are written in batches or for tracking down Out of Order events.

When force shifting an archive, the following message is displayed:

"Warning: This shift will clear data from the target archive. Are you sure you want to force an archive shift on <serverName> to a new archive?"

When Auto Archive Creation is enabled (having a value in Archive_AutoArchiveFileRoot), this is very misleading. A new archive will be generated and no data will be wiped.

This warning should only display if auto archive creation is not enabled and the archive will shift into the oldest shiftable archive.

pisrvstart.bat and pisrvstop.bat scripts should have "pilogsrvX64" added to them.  Currently all services except the "PIPC Log Server x64" are started/stopped by these scripts.

Certain plugins in PI SMT do not have features to support future data
1. Snapshot and Archive Statistics (is available only through piartool)
2. Current Data does not subscribe to timeseries in Update Manager
3. Stale and Bad tags

Storing the thread history(pibasess/piarchss etc) along with the connection history will help to better understand and troubleshoot issues on the archive and will serve as a kind of auditing on the behavior of connections.

OSI should get together and devise a proper data synching mechanism that should guarantee synching archives for all backfilled events and so on.

Through PI message logs I want to see which PI mapping was used for a Windows AD user, currently only the PI identity associated the windows AD is visible in the Logs. PI mapping information will give us more idea/facts about the particular Windows AD user.

As a user of the PI Data Archive, I would like the ability to give users access to create tags but not to be able to delete tags. This way they will not be able to accidentally delete tags but they still have the ability to create tags.

While no customers have asked for this directly, I have seen many customers ask how to check a tag for being stale. The solution to date assumes all tags have the same staleness timeout, which really is not the case most of the time.

This new "StaleTimeout" point attribute would be a duration (time span) customizable for each tag. There could also be a new PIPoint property called "IsStale" which could bounce the current value's timestamp off the "StaleTimeout".