In PI System Explorer → File → Server Properties, the Mappings tab loads much more slowly than the other tabs when you have a slow connection to the PI servers and the domain controller.

In tech support case 00589952, I found that the loading time of the Mappings tab was roughly the same as the total time from running the "net user /domain" command for each mapping. This 1-by-1 approach is not efficient. Note that in my case, I had a mix of local accounts on the PI AF server and AD accounts.

Please consider some of the following optimizations:
• If possible, for each computer that has at least 1 account that is used in a mapping, resolve all of its SIDs in a single call.
• Reuse previous SID resolutions. The same account can appear in multiple mappings and the same AD-connected computer can appear in multiple mappings, where it will appear at least once for each of its local accounts.
• Resolve the SIDs in parallel where possible.
• Request only the needed information in the SID resolution. That is, do not use a convenient function that returns excessive information and then cherry-pick from the result.

When the PI Analysis service determines an Analysis should be Suspended, it should also set any output Attributes to be Excluded. As the Analysis is Suspended, it will not output any results and if it has always been Suspended, the output Tags will never get created. Excluding the output Attributes will keep the Element looking clean and also allow dependent Analyses to go into a Suspended state instead of throwing an error when they can't find the Tags. Similarly it will prevent other applications (OSIsoft and third parties) from querying the Attributes and also throwing errors, causing performance issues.

Automatically suspended Analyses when the inputs are excluded was an extremely useful feature and has made supporting and maintaining an AF database easier. Automatically excluding the output attributes is a natural progression of this feature and will make AF database even more easier to maintain.

Although it is not advisable to modify the "System" digital state on a PI Server it is permissable as per the documentation on a "Minimal" basis.

In AF the matching "System" Enumeration set is "hard coded" and allows no modification at all.

This provides not only an inconsistancy in approach from OSIsoft, but also an Inconsistancy in values received from AF and from PI when the "System" digital state has been modified.

These inconsistancies leed to people questioning the validity of the data and the products being used to display it.

The "System" enumeration should be held in the AFEnumeraiton tables in the PFID database rather than hardcoded.

Suppose the following scenario: a user has 2 AF databases (a development and a production one), both containing same version of a template. The user deletes a few attributes and analyses from one element template (development), exports the xml and imports the same xml file into the production database. Today, the template in the production server remains unchanged, forcing the user to manually delete the attributes and analyses from production database (using either PI Builder or PSE).

The "import xml" function present in PI System Explorer should contain an option to allow users to reconcile templates, when importing a template into a system that contain the same template name. When that option is set, attributes and analyses that do not exist in the xml file should be deleted from the corresponding template (i.e., template with same name) in the database where the xml file is being imported.

A way to configure a notification rule to send to additional contacts when the severity status changes without creating a new analysis.

Customer use case:
Customer wants to scan devices. If a device fails to respond (I/O Timeout) over a short period of time, the event frame Severity is set to Warning and a notification is sent to IT. If the device remains offline for an extended period of time a child event frame is created and severity changes to major. When this occurs the customer would like additional people to be notified so they can go investigate the issue.

Workaround is to make a second analysis but users may prefer to keep it all under the same analysis.