Currently, there are two methods to 'shift' archives:
1. "ArchiveAutoArchiveFileRoot" set to blank
2. "ArchiveOverwriteDataOnAutoShiftFailure" enabled
Neither method shifts to dynamic archives. We have three sites that merged PI servers, thus half our archives are merged and dynamic. this negates any automated form of archive management.
I suspect the two shift methods came about thru an evolution, but there should be a way to 'rotate' thru all archive types so that we don't need to manually manage archives, mess with additional drives, etc.
What about a new tuning parameter?: 'Archive_DeleteOldestOnAutoShift'
We are only required to keep 'x' number of years of data, we have that requirement, but the drive is full. We can't easily add space, and we can't delete many archives at a time and maintain our minimum history, and we're too busy to delete archives every couple of days.
Help! Thank you!

As an AF designer I often have attributes indicating whether an element is enabled or disabled, this could be referring to a piece of equipment taken out of service, or a configuration element indicating a process is deactivated. The attribute is typically a boolean attribute, and I spent a lot of time going from one element to the next in order to disable or enable it, during operation and testing. It would be really helpful if I could tie this "Enabled" status attribute value to the icon PSE shows for an element, in order to quickly identify the elements which are enabled or disabled.

For normal AF databases I could create a PI Builder worksheet preloaded with the configs, but we normally put these configs in the Configuration database and this is not visible through PI Builder.

I envision the normal element icon to be grayed out if the status is disabled, or perhaps a cross/X over the icon. See attached image!

Related to this article: https://customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=000031389

I may have keys that are all spaces, and this may result in constant logging of the following error upon every database refresh (determined by /RATE in pihc.ini):

List <location 4 value>, searchForKey found invalid length key.

It may be hard to concoct a KEY wildcard that results in only the keys I desire, so using * as the wildcard, I am unable to prevent these all-space keys from being returned. As a result, the pipc/pisdk logs get flooded with these messages on each db refresh. As a user, I would like an option to suppress the logging of these messages.

Some metadata can be used in Analyses, which is helpful, but means constantly running an analysis on static data in order to use it at all in AF, which is inefficient, and we have been told to pull in data as a linked table into AF, which seems unnecessary as the data already exists in the PI environment.

Please allow us to pull in metadata as Attributes in AF, which then makes things much easier to view, check for accuracy, and update, using all of the extra capabilities of AF which are much more robust and easier to use than using Datalink or Builder.

Any attribute can already be used in analysis, so checking for things like missing Engineering Units (even though it is text,) or bad Compression/Exception settings, or anything else could be templatized and automated across the entire system, but not needed just to pull the data in every time there is a change.

It would be nice if these could be made as easy choices as child attributes for any PI Tag attribute. Having them in AF makes it much easier to search and grab all of them for any sort of structure that has been designed in AF at one time, whether it is by equipment type, location, etc.

By my understanding, only the PI User piadmin and the PI Group piadmins can ever have write access to the Database Security table PIDBSEC, and any write permissions to it assigned to any other PI User, PI Group, or PI Identity is ignored. However, PI Users and PI Groups are deprecated, and the use of piadmin is discouraged.

Please allow any PI User, PI Group, or PI Identity to be assigned write permission to PIDBSEC, just like the other Database Security tables, so then we can finally stop using PI Users and PI Groups and use only PI Identities.

The completion of this suggestion might involve creating a PI Identity that is equivalent to piadmin in the sense of having unrestricted access to the PI Data Archive regardless of any permission settings. If this suggestion cannot be implemented, then at least prevent any PI User, PI Group, or PI Identity from being given write permission to PIDBSEC in PI System Management Tools or other configuration tools, and make sure that piadmin's and piadmins's permissions cannot be edited in or deleted from PIDBSEC's security (i.e. they should remain as piadmin: A(r,w) | piadmins: A(r,w))

We are creating hundreds of different attributes in AF, mostly based on templates and using these in PIVision.

One thing that is annoying is when you make the PIVision image you have to manually change the colour of the symbol you use/trend you created etc to reflect the medium of the attribute that is used. Sometimes you even have to change the HEX colour code since it does not match the standard colour palette.

What I am suggesting is to have a Colour Datafield in System Explorer for attributes.

Here we can define the colour (via HEX code or another way), so when this attribute is used in PIVision, the colour is automatically selected.

No Colour Set = Manual/Default PIVision Colour.
Colour Set = Colour chosen by default in PIVision.

Should be overridable in PIVision if people wish etc.

Currently PI System Explorer views lots of stuff that is not used by most users (ports, models etc.) also, there are some things that may depend on decisions of particular client - for example, I don't want my users to use Formulas.
I suggest to provide way to either customise PI System Explorer on each client (choose which part of Explorer is visible, which not - this seems to be a easier way to implement) or move that config to AF server so that every instance of PI System Explorer shows only that content which is allowed on connected AF server. Is such case I would be able, as an admin, for example to disable Formula data reference on the server and thus avoid using it.

Currently you can only run a single PI Analytics instance at a time. We have two VMs running PI Analytics in a failover situation, but this means that one of the VMs is sitting idle 99% of the time.

We are starting to hit the limits of scaling with analytics falling behind. Ideally, the analytics should be able to run on multiple VMs.

For example, if you have 10 AF Databases and 2 Analytics servers, it should run the analytics for 5 of the databases on each VM. In a failover situation it could send the Analytics for all 10 databases to the online server. In this way if you run into performance issues you could increase the number of Analytics servers to improve performance (at least across multiple AF Databases). If you added a 3rd server, it would split the jobs 3+3+4 based on AF Databases.

You would still need to ensure the servers are adequately specified to handle the load of a single AF databases calculations, but this would go a long way to improving the problems we are having with performance.