Troubleshooting PI AF SDK Connections from ASP.NET Web Services on IIS

Connecting to the PI Asset Framework (AF) using the AF SDK from an ASP.NET web service can be straightforward during development, but deployment to IIS—especially on a different server than the AF Server—often unveils authentication and connectivity challenges. In this post, we’ll discuss common pitfalls and best practices for stable, secure connections between your web service and PI AF, with examples and important security considerations.

Development vs. Deployment: What Changes?

During local debugging, web applications usually run under your user account, which often has the necessary permissions for the AF Server and database. However, when deploying to IIS, web applications run under a specific identity—typically the Application Pool’s account. This identity may not have access to remote resources such as the PI AF Server, leading to connection failures with unclear errors.

Common Error: Cannot Connect to AF Server

A frequent issue reported is:

"Cannot connect to AF server." (especially when IIS runs on a machine separate from the PI AF Server)

Let's break down why this occurs and how to solve it.

Key Areas to Check

1. Application Pool Identity

IIS Application Pools control the security context (user identity) under which your web application runs. If the Application Pool is set to LocalSystem or NetworkService, those identities must have permissions on the AF Server. If using a custom domain account, ensure it's granted adequate access to the AF environment.

Recommendation:

• For production, use a dedicated domain account for the Application Pool.
• Ensure this account is granted at least read access to the PI AF Server and AF database.
• Test connectivity by logging into a remote machine with the same credentials and using PI System Explorer.

2. Network Connectivity and Firewalls

Confirm that the IIS machine can contact the AF Server over the network. Firewalls and network segmentation between application and AF servers can impede connectivity.

Recommendation:

• Use diagnostics tools (ping, telnet, or Test-NetConnection) to verify connectivity.
• Ensure necessary ports for PI AF communications are open.

3. Authentication and Delegation

If your web service must impersonate the end-user (e.g., for client-level auditing or data security), you'll need Kerberos delegation (double-hop authentication). This is complex but necessary if the same security context needs to be passed from client, through IIS, to the AF Server.

Recommendation:

• Enable Kerberos for both the client-to-IIS and IIS-to-AF-Server hops.
• Configure SPNs and delegation for the Application Pool account.
• Consider if impersonation is truly needed; often, running under a dedicated service account is easier to maintain.

4. Selecting the Right Web Service Technology

The legacy ASP.NET Web Service (ASMX) technology is less secure and less flexible compared to WCF (Windows Communication Foundation), which offers better integration with Windows authentication and delegation.

Recommendation:

• For new implementations, build your PI interfaces with WCF rather than ASMX web services.

Example: Securely Connecting to AF Server

Here is a C# snippet demonstrating a connection using AF SDK, accounting for security context:

using OSIsoft.AF;
using OSIsoft.AF.PI;

// Initialize PISystems collection
PISystems piSystems = new PISystems();

// Connect to a specific AF Server by name
PISystem piSystem = piSystems["AFServerName"]; // Replace with your AF server name

// Access a specific AF Database
AFDatabase myDb = piSystem.Databases["AFDatabaseName"]; // Replace with your AF database name

// Use myDb for your AF queries and operations

Note: When hosted in IIS, these calls use the Application Pool identity unless you explicitly pass credentials or configure impersonation.

Best Practices Recap

• Always grant appropriate access to your AF Server and databases for the account under which your IIS Application Pool runs.
• Test permissions with a non-service application (like PI System Explorer) using the same identity.
• Use service (domain) accounts for services, not built-in accounts.
• For client impersonation scenarios, properly configure Kerberos delegation and avoid storing user credentials in code.
• Prefer WCF over classic ASMX for new web-based PI interfaces.

Conclusion

Authentication and context are often the root of AF SDK connection problems from remote IIS-hosted applications. With careful configuration of your Application Pool identity, network, and (if needed) Kerberos delegation, your web service can reliably and securely access PI AF resources. For step-by-step guides on IIS and Kerberos configuration, consult both OSIsoft and Microsoft documentation.

---

Have you experienced similar PI System connectivity issues? Share your lessons learned or questions below!