How to Move a PI Collective Between Active Directory Domains: Best Practices and Pitfalls

Migrating a PI Collective from one Active Directory (AD) domain to another is a significant system administration task. It requires careful planning and execution to avoid service disruptions and maintain data integrity. In this post, I'll outline the key considerations, highlight common pitfalls, and provide guidance on the recommended order of operations for moving primary and secondary servers—using as an example PI Data Archive version 3.4.375.80 (32-bit), though many principles still apply to current versions.

Why Move a PI Collective Between Domains?

There are several reasons you may need to migrate a PI Collective between AD domains:

• Organizational changes (e.g., company mergers, acquisitions, or restructuring)
• Security policy updates
• Domain decommissioning
• Standardization efforts

Key Considerations Before You Begin

1. PI and Domain Prerequisites

   • Ensure you have full backups of your PI Data Archive servers and interfaces.
   • Confirm your target domain is fully operational, with DNS and trust relationships configured.
   • Have appropriate Active Directory security groups and user accounts prepared for PI service accounts.
   • Review OSIsoft’s documentation for your specific PI Data Archive version, as some steps may differ for 32-bit systems or older releases.

2. FQDN Resolution

   • All PI clients and interface nodes must be able to resolve the Fully Qualified Domain Names (FQDN) of both primary and secondary members before and after the move.
   • Test forward and reverse DNS lookups for all PI servers from all clients.

3. Service Account Migration

   • Update PI Data Archive and interface service accounts to exist and have the required permissions in the new domain.
   • If the syntax for service accounts is changing, update all service dependencies.

4. Trust and Security

   • Review and reconfigure PI trusts, mappings, and identities, as well as any AD-integrated security configuration.
   • Validate that PI’s internal security (including PI Mappings and PI Identities) will authenticate as expected in the new domain.

Recommended Migration Order

1. Which Server to Move First: Primary or Secondary?

Typically, it is recommended to migrate the secondary server(s) first. This strategy allows:

• Testing system functionality within the new domain while keeping the primary (active) server untouched, reducing the risk of downtime.
• Rolling back changes more easily if issues arise.

Once the secondary server migration is complete and verified, proceed with the primary. After the primary is moved successfully, revalidate the entire collective operation.

2. Step-by-Step Process

1. Update DNS Records: Ensure both old and new domains' DNS can resolve all collective members.
2. Change Secondary Server Domain Membership:
   • Remove from old domain, join new domain, reboot as required.
   • Update PI services to run as the new domain accounts.
   • Verify server can still communicate with collective members and clients.
   • Test failover scenarios.
3. Update Clients/Interfaces: Confirm that interface nodes and clients can resolve and connect to both domains during the transition.
4. Migrate Primary Server: Repeat above steps for the primary member.
5. Synchronize Configuration: Re-check collective status, synchronization, and perform full system validation.

Common Pitfalls to Avoid

• DNS Resolution Failures: Incomplete DNS updates can lead to connectivity issues for both PI servers and clients.
• Permission and Trust Issues: Failing to update PI trusts, service accounts, or AD security groups can break authentication.
• Version Compatibility: Older PI versions (like 3.4.375.80) may require additional configuration—refer to release notes and technical support documentation.
• Forgotten Interfaces: Some interface nodes may have hard-coded trust or security configs that need manual updating.
• Improper Testing: Always test both failover and routine operation in a non-production environment before performing the migration.

Engage with OSIsoft Technical Support

Given the complexity and risk of downtime, it's strongly recommended to involve OSIsoft’s Technical Support team when planning and executing a PI Collective domain migration. They have the tools, expertise, and up-to-date best practices tailored to your PI version and environment.

Conclusion

Migrating a PI Collective to a new Active Directory domain is more than just changing server memberships—it touches all aspects of authentication, name resolution, and system configuration. With careful preparation and a methodical approach, you can minimize disruption and ensure a smooth transition.

If you have real-world experiences with such migrations, or tips for avoiding lesser-known pitfalls, please share them in the comments!