As a PI administrator I would like to be able to create multiple instances of "PI Analysis Service" windows service for these reasons:
- avoid new potentially problematic analysis from affecting the ones that are operational and working correctly by setting one production instance and one test instance for example.
- every instance could have its own log files and we could move some analyses to a new instance to troubleshoot them
- make possible to distribute the resources usage for asset analytics on more than one server

The idea was already declined in "https://feedback.osisoft.com/forums/555148-pi-server/suggestions/33839161-multiple-instances-for-asset-analytics" nevertheless i think this should be considered for rolling out AF in big companies.

As a customer with a large foot-print of on-prem PI System software across multiple sites, I need a solution for health monitoring and diagnostics that allows me to identify issues (potential or current) with any component of the PI System or its data flow. PI System is a mission-critical application in my organization and any downtime has serious impact to the operations.

As a PI Administrator, I have been asked to use the PI System Monitoring AF toolkit, which is a service, and not a licensed product by OSIsoft/AVEVA. My organization has invested time and resources on implementing the toolkit and found very limited value (e.g. no capabilities to monitor PI Vision, PI Connectors, limited PI AF monitoring, no upgrade process, primitive analytic rules). Furthermore, the onus is on the customer to determine the health of the system, forcing us to become experts on the inner workings of the PI System. We would rather invest resources on building business value on top of the PI System.

In the DA collective there is a function called "Failback". The function is described as:

<< When the collective member which the client application was connected to becomes unavailable, the client connection starts monitoring when the member becomes available again. When it happens, it should switch back to that member.

This is done by the client application (it is not anyhow forced by the server) and it is done to:

Honor connection priorities
Restore connection distribution (if member priorities are equal). >>

The problem with this is that if primary has been down for a while the buffer needs to fill the gap. The client can not access real time data until the buffer is backfilled.

I would like the failback function to be optional. In that way the clients can have real time data continiously.

We are running a central DCM Server in our site to maintain the dataflow between different UA Connectors and different DataArchive/AF pairs. We use this DCM to restart Connectors and to browse and select new Tags on a OPC UA Server.
As central Admins, we need the input from our plants in order to select the proper tags to be transmitted into DataArchive. As DCM tagbrowsing and selection is easy to use, we would like to provide our plant DCS engineers the possiblity to do the selection on their own, without our support. But as we are running DCM as central service, and there is no user management right now, every user who has accees can configure tags and routing for every connector, plant and DataArchive. We would like to have the possbility to provide plant users access to their Connector/Datasource only and only for Tagselection.

Having the PI Relay for OPC UA Connector running on a different machine than the actual connector is a good Idea, as we are now able to provide Windows credentials for AF Access without Credential manager.
On our Site we are running several smaller PI Server and would like to have one or a few central Relay server instead of a Relay per DataArchive. However, this is not possible yet as Relay Service can not be instanciated and only provide a 1 by 1 connection to a DataArchive/AF Server pair. Our workaround is to install the Relay service locally on each Dataarchive, but we would like to keep this centralized for Maintenance reasons.

Following KB01345 & 000036461 we have to manually add dependency where applicable.
Please consider adding similar service dependency than we have via PI ICU for new interface (depend on pibufss):
- AFService depend on relevant MSSQL$<SQLInstance> service if SQL Server = AF Application server
- AF Analytics, AF Notification & PI DAS RTQP depend on AFService if on same host
- PI Web API Crawler on PI Web API
- PI Web API on AFService if target AF is on same host
- PI Web API on Buffer subsystem if already configured at the moment of install/upgrade
- AF Analytics on Buffer subsystem if already configured at the moment of install/upgrade
- Add possibility for easier dependency on Buffer by Random, RampSoak & Performance equation