Considerations when moving a Historian from existing domain into a new domain

Hello,

we have to migrate a distributed SP form existing domain into a new one.

Difficulties: It is aPharmaceutical company and complete migration shall be done in place, without downtimes

Historian acquires data from a redundant App Engines

Any experiences, best practices, etc? What is to consider? Is FQDN somewhere in database?

Or is it impossible to move forward without downtime?

Thanks 

Stephanie

  • This probably warrants more than just a few tips in a forum post, but the first question: Is this about migrating between TCP domains (e.g. "myhist.bob.com" to "myhist.joe.com") or Windows domains (e.g. authentication/identity, "BOB\JohnDoe" to "JOE\JohnDoe") or both? Migrating TCP domains will be easier, since it only really impacts name resolution (and you can force some backward compatibility using standard name resolution tools), but changing the identity is more complicated--making that change without downtime would require both domains to be online in parallel and to have some type of shared trust.

    For Historian, by default in the "Runtime" database all the self-references will be based on the NETBOIS machinename, but there may be user-supplied references to other nodes (e.g. Remote IDAS, I/O server, "partner" Historian, Replication Server, etc.) and those could use the FQDN, IP addresses, etc..

    For the Historian part, you'll want to set up a "partner" Historian (if you haven't already)--that way you can migrate each one separately. 

  • Hi   , I have posted in the other SP question that you have asked