AnsweredAssumed Answered

Guidance requested for 3.4.385.77 to 3.4.425.1435 upgrade

Question asked by RickRae on Dec 31, 2019
Latest reply on Jan 2, 2020 by jyi

Greetings, all.  I've run into an issue that doesn't make sense to me, and I'm hopeful someone here can point me in the right direction.  The "executive summary" of sorts is bolded.

 

Background: We are currently running 3.4.385.77 (2010 R3) across four Windows Server 2008 machines which host a two machine collective, PI AF, and its SQL server.  We are in the process of upgrading to Windows Server 2016 company-wide, which I saw as an opportunity to finally update our PI system as well.

 

Due to IT policies all machine names and IP addresses must change; additionally, we must use SQL Server 2016.

 

Stated best practice is to upgrade PI after moving to any new environment.  Because AF 2010 R3 is not compatible with SQL Server 2016, I chose to install the latest release of AF (which is compatible with our older PI Data Archive system per KB01603).

 

Both the new SQL setup/scripts and AF installed without issue.  However, when attempting to install the old PI Data Archive package the installer states (in part),

The client version '2010 R2 (2.3)' is incompatible with this version of the PI AF Server '2.10.5.9075'. Client version must be 2010 R3 (2.4) or later.

 

This confuses me because the installer itself indicates it is installing 2010 SP1, which is 2010 R3/3.5.385.77 per the install list, KB01603, article 000025130, and other related resources.  So, I am at a loss as to why this complaint is being thrown, or what to do about it.

 

I should also note that AF isn't really utilized here; we only have it set up to support a few notifications which can easily be replicated manually, so it doesn't matter if they don't survive the migration/upgrade process.  

 

_____

 

On a separate but related question, our system is somewhat lightly loaded and everyone connects to the Collective Primary; loss of the Secondary during the migration/update would not be an issue, so I wonder:

 

1) If instead of joining a newly installed server to the existing collective as a secondary/promoting/dropping/adding the new secondary, perhaps migrating to a single new Data Archive machine, updating to the current PI release, and then transitioning to a two-member Collective would make more sense?

 

2) If there is a path that supports installing 3.4.425.1435 to the new hardware and then importing the archives/point database/etc. from the existing 3.4.385.77 system. I've read several very positive posts about forward compatibility across versions, so I'm wondering if this might be a better option given our use case.

 

Both of the above would negate the installer's current objections; the second would also support interface operation and security configuration testing BEFORE putting the newest release into production.

 

Any wisdom anyone can provide would be greatly appreciated.

 

Thanks,
Rick

Outcomes