Bridging the Gap: Configuring PI Trusts Across AD and Workgroup Domains

When working with legacy infrastructure setups involving OSIsoft PI Systems, particularly those that span across different network domains, managing user access can become a critical challenge. This is especially true when PI Servers are set on standalone Workgroup domains, while users operate within an Active Directory (AD) environment. In this blog, we'll explore a common scenario faced by PI System administrators and offer insights into resolving connectivity issues effectively.

The Challenge: Cross-Domain Trust Configuration

The described scenario involves a PI Server on a standalone Workgroup domain, with the need for users from an AD Domain to access PI archive data via OSIsoft ProcessBook. This situation is further complicated by a legacy PI system version and network configuration issues.

Unraveling the Networking Constraints

In legacy setups, particularly those dealing with older versions like PI Server 3.4.385 on Windows Server 2008 SP2, administrators often resort to PI Trusts to grant access. However, this method has become dated and suboptimal, especially with advancements in security protocols.

In the case at hand, the PI server was equipped with dual NICs - one on each of the business and operations subnets. Initial attempts to configure PI Trusts using machine name, domain/user credentials, and client applications (such as ProcessBook) failed. The server logs reported disconnections citing "No Trust."

Diagnosing the Real Issue

After ensuring connectivity through Ping and RDP by addressing the PI server through both name and IP, the focus remained narrowly on PI security settings. However, upon changing the destination IP address for business clients to the business-facing NIC on the PI server, the connectivity issue was resolved. Prioritizing this NIC within the server's configuration further stabilized the connection.

Best Practices for Connecting PI Systems Across Domains

Usage of Windows Authentication

While PI Trusts can solve immediate access issues, they are not ideal from a security perspective. Upgrading to newer versions of PI that support Windows Authentication offers a more robust, secure, and compliant method of managing user access.

Network Configuration Considerations

Ensure that network interface cards (NICs) on dual NIC servers are correctly prioritized, with explicit configurations tailored for client connections.

Leveraging PI Square and Documentation Resources

Community forums like PI Square are invaluable for troubleshooting when facing uncommon configurations or challenges. Additionally, OSIsoft’s LiveLibrary provides access to documentation that can assist even without a direct service agreement.

Upgrading the PI System

For long-term strategic planning, encouraging the transition toward newer, supported versions of the PI System will improve reliability and feature enhancements and align with modern IT security practices.

Embracing structured troubleshooting and aligning solutions with current technology standards ensures that organizations maximize the reliability and security of their PI System. While resolving immediate connectivity through appropriate IP configurations, investing in system upgrades and revisiting secure access methodologies should remain high on the agenda for any PI infrastructure manager.