As a PI System administator of a busy PI Data Archive, I find that my message logs are unwieldy. I can miss important messages in the flood of connection messages and other repetitive messages. I would like to be able to search my message logs while excluding certain message types (like in Event Viewer). For example, I would like to be able to run a query that excludes connection messages from pinetmgr and "User query failed" messages so I can quickly narrow in the problem I'm looking for.

Filtering on severity has proven an imperfect solution because sometimes important messages are written with a low severity level.

There are other similar ideas out there on this site but I would like to see the ability to skip numbers in the Digital States Enumeration. We have areas of the plant that have states which don't map well to a 1,2,3.... set of states. Some are bit settings and others are just high numbers. Let users skip numbers and enter what they want (100,200,300, etc.) Numbers that aren't defined will be filled in by the system as "undefined" or something similar when shown in vision. It's difficult to create a set with 250 values and doesn't need to require a user to individually create a lot of "blank" values to get to the one you really want (I know you can import too but still).

PI System Management Tools is more of a client-side program, so it does not make sense for it to be packaged with a server-side program like the PI Interface Configuration Utility. This increases the size of the install kit, increases the extraction and installation time, and leaves the user with lots of junk programs that they are not sure if they can safely uninstall (PI Interface Configuration Utility, PI Buffer Subsystem, PI Spt DLL, PIGenericNames DLL).

Please remove anything specific to the PI Interface Configuration Utility from the PI System Management Tools install kit. Also grey out "Interface Configuration Utility" in the Tools menu to reflect this change.

Schedule data archive shifts occur and create archive files based upon a Minimum Archive Size calculation. This calculation is based upon the total count of record numbers. When large amounts of tags are deleted, the total number of tags is reduced but the record number count remains the same...thus creating a huge discrepancy between the two counts.

The minimum archive file size is based on total record numbers. Thus, if you delete a large number of tags (e.g. Reduce a 5M tags system down to 1M tags after splitting a collective into multiple collectives)....then the system will artificially create very large archive file sizes which are filled at a low percentage. This calculation result is different from the Archive_AutoArchiveSize calculation which looks at the count of active tags. The deviation between the two leads to confusion and difficulty properly scheduling archive shifts, along with generating incorrect % full results (which look at the total record number count, not the total tags....this would be artificially false low).

If the Compressing attribute of a PI Point is set to Off, then the compression settings are greyed out, which makes sense because they are irrelevant if Compressing is Off.

However, if a PI Point has its Archiving attribute set to Off, nothing is greyed out, even though the exception and compression settings and the Compressing attribute are all irrelevant.

I propose changing the layout of the Classic tab to reflect the relationship between these settings. If Archiving is Off, do not show the user the exception settings, compression settings, or the Compressing attribute. If Archiving is On, show the exception settings and the Compressing attribute. Only show the compression settings if Compressing is On.

For extra clarity, consider making an exception equivalent to the Compressing attribute.

When this tuning parameter is enabled, it prevents a PI Collective from being flagged as out-of-sync when some of the PI Collective members can resolve the SID of a PI Mapping and others cannot. However, by default, this tuning parameter is hidden and disabled.

This tuning parameter is important when you are trying to replace all PI Trusts with PI Mappings to accounts that are dedicated to each instance of each PI service and you do not have the power to create domain accounts and/or the creation of dedicated domain accounts is not a priority for the organization as a whole and so it never gets done. The next best option is to use NTLM authentication and set up a local account with the same user name and password on all PI Collective members for each instance of each PI service. Each local account requires its own PI Mapping, and each PI Collective member has a copy of each PI Mapping. However, a PI Collective member cannot "see" the local accounts on any computer other than itself, and so it cannot resolve the SIDs of accounts that are local to the other members, which causes the PI Collective to go out-of-sync unless Base_AllowSIDLookupFailureForMapping is enabled.

The description of Base_AllowSIDLookupFailureForMapping provides a different use case: allowing the PI Collective to remain in-sync even when some members are in different, untrusted Windows environments.

The main point is that this tuning parameter is important for the adoption of PI Mappings, so please make it visible by default so that it can be more easily discovered and set by administrators.