Double listing of components in Control Panel

After you have upgraded a FactoryTalk Historian SE suite from version 3.00 or 3.01 to a newer one, some components of the suite are listed in Control Panel for both the upgraded-from and the upgraded-to versions.

The list of the doubled components consists of, but is not limited, to:

• FactoryTalk Historian SE WCF Installer
• FactoryTalk Historian SE Server Core x64 Installer
• FactoryTalk Historian SE Server Core Installer
• FactoryTalk Historian SE RA Components
• FactoryTalk Historian SE RA Components Folders
• FactoryTalk Historian SE Live Data Interface

Despite the misleading information, the only suite that is installed is the upgraded version. The listing of the doubled components has no impact on the products' functioning.

Special characters in point sources created in the Administration Console

When you create point sources in the FactoryTalk Administration Console, avoid using special characters (such as " or |) in the point source names, since they may corrupt the list of point sources that is sent to FactoryTalk Historian SE.

Removing license activation assignments after creating points for the FTLD interface

Avoid unassigning the FHSE and/or FHLD license activations in the FactoryTalk Administration Console when you have already created points for the FTLD interface, because you will not be able to create any new points for any point sources on the server.

Point in Use values don't refresh after removing all points

If you delete all points that you have, the information on the points in use will no longer be refreshed in the System Management Tools and the FactoryTalk Administration Console. To refresh the point counts, restart the FactoryTalk Historian SE server.

Delay in refreshing the Points in Use values

The Points in Use values in the FactoryTalk Administration Console are refreshed and updated 20 minutes after the restart of the FactoryTalk Historian SE server.

Sum of point counts is understated

The sum of point counts from the new Rockwell license activations (FTHSE) and the third-party license activations that equals 500000 is understated in the System Management Tools.

Point in use from certain point sources appear to be added to the Rockwell license pool

Points in use of the FHSS, FTBOINT, and/or PIFTBOINT point sources appear to be added to the Rockwell license pool in the FactoryTalk Administration Console.

The FHSE.H2H and FTBAInt license activations set their point sources (FHSS, FTBOINT, and PIFTBOINT) to unlimited. The correct behavior of unlimited point sources and their allocations in the FactoryTalk Administration Console is that they are listed in the Point Sources tab, under Interface Type, but the number of their points in use is not reflected in the number of points in use of the individual license pools (Rockwell and General).

If you allocate the FHSE.H2H and/or FTBAInt license activations and create points for the FHSS, FTBOINT, and/or PIFTBOINT point sources on the server, they are correctly handled by the system, but the points in use of these point sources appear in the FactoryTalk Administration Console as if they are added to the Rockwell license pool, which is an incorrect behavior.

To get a correct calculation of points in use of the Rockwell license pool, add up all the points in use of the FHSS, FTBOINT, and/or PIFTBOINT point sources under Interface Type Allocation, and then subtract them from the points in use of the Rockwell interface type.

Can't revoke the activation assignment

If you have assigned a license activation to your Historian server in the FactoryTalk Administration Console, and the license activation file is no longer visible in the FactoryTalk Activation Manager (for example due to connection problems), you will not be able to revoke the assignment of the activation.

To solve this issue, make sure that the license activation file is available in the FactoryTalk Activation Manager at all times. It may be done in many ways, depending on the cause of the problem. For example:

• If the license activation files are stored by the FactoryTalk Activation Manager on your local machine, restore in the FactoryTalk Activation Manager the missing license activation file, or assign another file of the same license activation type as the missing one. The number of points available per license activation may vary.
• If the license activation files are stored by the FactoryTalk Activation Manager on a remote machine, reestablish the network connection to that machine, or connect to another FactoryTalk Activation Manager server that stores license activation files of the same type as the missing one. The number of points available per license activation may vary.

Running PISDKUtility for the first time after the installation takes time

When you run PISDKUtility on your Historian server for the first time after its installation, the starting process may take some time. It results from the fact that PISDKUtility fails to identify itself on the server. The problem does not apply to any future occurrences of starting the utility.

Backward compatibility with FactoryTalk Security authentication

Since FactoryTalk Historian SE 3.0, Historian security has been configured using Windows-based authentication. The security of earlier versions of FactoryTalk Historian was based on configured authentication using FactoryTalk Security. To support backward compatibility, during the installation of the FactoryTalk Historian SE server, trusts for FactoryTalk Security are created in the System Management Tools.

Incorrect permissions of points (tags) created in the PI Performance Monitor

The points (tags) created in the PI Performance Monitor use piadmin, piadmins, and PIWorld permissions instead of the permissions defined in the PIPOINT table. This behavior does not reflect the current security model of FactoryTalk Historian SE, in which points should be created with the access permissions defined in the PIPOINT table. To solve this problem, do the following:

To correct point (tag) permissions:

27. In the System Management Tools, expand IT Points > Performance Counters.

28. Select counter entries for which you want to create tags.
29. In the right pane of the System Management Tools dialog box, right-click the listed entries, and then click Properties.
30. In the Properties dialog box, go to the Security tab.
31. Under Point Security, remove piadmins, and then replace it with a group that should have access to point attributes.
32. Under Data Security, remove piadmins, and then replace it with a group that should have access to point values.
33. Click OK to apply the changes.

Now you can create the tags.

FTHAdministrators group does not let creating data points

If you want a user to have privileges to create data points, you need to either map the user to the piadmin user or to the FTHEngineers group. Being mapped to the FTHAdministrators group does not give you the privileges to create data points.

Incorrect interface state logged to the archive when the primary interface is disconnected

When the primary interface is disconnected from the network, the wrong interface state is logged to the archive. In the event that the current primary interface (intf1) is disconnected (for example, the Ethernet cable to the Intf1 computer is cut) from both the file share and the primary FactoryTalk Historian SE, the backup interface (intf2) will take on the primary role. In this situation, the disconnected primary interface will also maintain its primary role, as the algorithm used by the failover state machine specifies that an interface will never voluntarily give up the primary role. Although it is up to the backup interface to take over the primary role, Intf1 is blind and does not know what intf2 is doing. As such, it maintains its primary role. Because of the complete disconnection, Intf1 should not be collecting any data outside of the status tags. When it comes back online, you may see some incorrect values for the interface status tags after the old primary interface comes back online. This is because even though intf1 is blind and disconnected, it is still generating events for the status points, and will send them to the Historian server once it comes back online.

Primary and secondary servers go down when using an SMT collective

If the primary and secondary servers go down when you are using a System Management Tools (SMT) collective, it is possible that the SMT has crashed. In this case, you will need to re-launch the SMT.

SMT may crash when the secondary server is booted up first

In a collective configuration, if a secondary FactoryTalk Historian SE server is booted up first, then the SMT might crash when attempting to stop and re-start the application.

Data loss after the primary interface node is disconnected

If the FactoryTalk Historian SE primary interface node is disconnected when the server is configured as a collective and the interface node is configured redundant, data will be lost for about 8-10 seconds.

SMTHost.exe memory leak while performing disconnect/reconnect tests

When performing disconnect/reconnect tests (of controllers and interface node Ethernet cables) on the Historian server, there is a slight SMTHost.exe memory leak. If you restart the System Management Tools, the memory for SMTHost.exe is released and the memory consumption goes down.

Third-party tag licenses not recognized by the Administration Console

If you make a FactoryTalk Historian SE server(s) a member of a collective, you must restart the server(s) after creating the collective. If you do not restart the server(s), the FactoryTalk Administration Console will not recognize any of the third-party tag licenses you have on your server(s).

Loss of polled tags data while disconnecting and reconnecting a server in a collective

If a server in a collective is disconnected from the network and is reconnected to the network later, it might lose the first 20 seconds of polled tag data during both the disconnection and reconnection. Use advised tags if a 20 second data loss is unacceptable.

Manual switchover behavior with the current primary interface failover ID equal 1

If the current primary interface failover ID equals 1, then a manual switchover can NOT be accomplished by changing the value of the Active_ID to "2" in the System Management Tools.

PIbufss fails to initialize on a newly redundant interface pair

PIbufss does not initialize on a newly redundant interface pair if the FactoryTalk Historian Live Data Interface (FTLD) is connecting to a collective Historian server and the following applies:

• API hostname in the Interface Configuration Utility (ICU) is addressed with FQDN.
• Buffer servers are set to Path (FQDN).
• The piclient.ini file does not have Historian servers addressed with FQDN, but instead they are addressed with names only.

As a result, buffering does not work, and there are no errors in the system.

Incorrect scan class statistics generated by health points

Scan class statistics generated by health points in the Interface Configuration Utility that is running on an interface computer are incorrect.

Discovery rule XML file corrupted when defined with an apostrophe mark character

If you type the apostrophe mark character (') in a discovery rule in the rule name definition list (marked in red in the figure below), and then save the rule, the XML rule file will be corrupted and you will not be able to use it in the Rule Editor. To repair the file, open it in an external XML editor, and then remove the character.

Missing points created in the main folder on the HMI server

If an area contains both an RSLinx Enterprise and an HMI server, and you search points from both servers using the Discover Historian Points tool in the FactoryTalk Administration Console, the points created in the main folder on the HMI server will not be found.

Discovery rule can't be modified by another Windows system user

A Windows system user cannot modify a discovery rule that has been created by another Windows system user.

Installing FactoryTalk Historian Live Data Interface may fail if the OPC DA interface is running

To ensure a successful installation of FactoryTalk Historian Live Data Interface, it is recommended that you stop the OPC DA interface before starting the installation.

Removing FactoryTalk Historian Live Data Interface may fail if the OPC DA interface is not removed first

To ensure a successful removal of the FactoryTalk Historian Live Data Interface, it is recommended that you delete the OPC DA interface service before starting the removal process:

15. Open the Interface Configuration Utility.

16. From the Interface list, select the OPC interface that you want to remove.
17. Click to stop the interface if it is running.
18. Click to delete the interface.
19. Confirm the deletion in the message box that appears. This action cannot be undone.

Removing some FactoryTalk Historian SE suites may render the remaining ones nonfunctional

If you have several FactoryTalk Historian SE suites installed on the computer (e.g., the FTLD interface and FactoryTalk Historian SE Management Tools), and you remove some of them, the remaining suites may not work. To resolve this problem, remove all the suites installed on the computer and reinstall the desired FactoryTalk Historian suite.

Data transfer from FactoryTalk Historian ME to FactoryTalk Historian SE requires a trust

If you want to transfer data from FactoryTalk Historian ME to FactoryTalk Historian SE, create a trust on the FactoryTalk Historian SE server with the PI Identity option pointing to piadmin.

Managing users that are members of several Historian security groups

The Historian users are configured so that some of them, depending on the role they fulfill in the system, are members of several Historian groups. As a result, these Historian users get privileges from all the groups to which they belong.

In the previous versions of FactoryTalk Historian SE (2.20 and earlier), if you wanted to give a Windows user privileges from several Historian groups, you mapped Windows users to relevant FactoryTalk Security groups using the FactoryTalk Administration Console. The FactoryTalk Security groups, in turn, were mapped to individual Historian users by means of trusts.

Since FactoryTalk Historian SE 3.0, which introduced a new security model, if you want to give a Windows user privileges from several Historian groups, create mappings using the System Management Tools following either of the methods:

• Create a mapping between an Active Directory (AD) group and a Historian user. In this way, the Windows user from the AD group used in the mapping gets privileges from all the Historian groups to which the Historian user referred to in the mapping belongs.
• Create 1-to-1 mappings between each AD group and a corresponding Historian group. If the Windows user is a member of only one AD group for which you have created the mapping, they will get privileges only from the Historian group referred to in the mapping. If you want the Windows user to get privileges from several Historian groups, make sure the user is a member of all the AD groups that are mapped to the Historian groups whose privileges the user should get.

Creating a collective with Historian servers fails

Creating a collective with FactoryTalk Historian servers will fail unless the servers are members of the same network domain.

SMT crashes when trying to view licenses on a Historian server

When you try to view licenses on a Historian ME server using the System Management Tools, the application crashes and an error message appears.