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

Question

Hello, 
 we have to migrate a distributed SP form existing domain into a new one. 
 Difficulties: It is a Pharmaceutical 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

Elliott Middleton · Answer

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.

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

Top Replies