Migrating PI servers to a new domain. Anything to consider? I have five PI servers (2012), several interface boxes running PI-OPC and UFL. All of them are migrating to a new domain.
Hi Dean, do you have any collective/failover?
I found a in our database one case with a detailed explanation of things that should be taken into account:
- NS Name Resolution issuesIf your clients are connecting to the server using an IP address (and the IP address is not changing) then no further action needs to be taken. If the clients are connecting to the PI server by name however you must ensure that the PI System server name is correctly configured in the DNS system that the clients will be using. This holds true for scenarios where the PI Server is in a different domain than that of the clients as well as the same domain. The requirement boils down to correct name resolution for the PI System Server for the clients.In many cases such as with PI-API connections Reverse DNS lookups are also required to be correctly configured. If reverse DNS is not available a HOSTS file lookup is used. If your system was previously using a HOSTS file to facilitate Reverse DNS lookups this file will also need to be corrected or Reverse DNS lookups will need to be properly configured.
In terms of client connections you could do the following to ensure a proper move:1) Map the old Fully Qualified Domain Name (FQDN) to the new FQDN via the Domain Name System (DNS) server 2) The clients will find the server and change the information in the Known Server Table (KST) to match the new FQDN; nothing needs to be done on the clientsAnother option for client connections would be a server alias. You could create a server alias that points to the old FQDN. You could even try doing both of these to ensure that clients are able to connect to the PI Server.
To make an alias go to About-PISDK, open up the Connections manager from Files > Connections. Then go to Server > Aliases and enter a new alias that points to the old PI Server name including the old domain (such as cdriscoll6400.osisoft.int).
- Trust table entriesIf clients are also changing to a new domain name then there is the potential that defined trust table entries will no longer properly match. If any trust entries are using domain membership via the "Domain" column in the trust table this will need to be changed to match the new domain of the client. Likewise, any trust table entries that are currently defined with an "IP Host" entry that uses the Fully Qualified Domain Name, e.g. client1.mydomain.com as opposed to simply "client1", will need to be changed to reflect the new domain name. API Connections will use the Fully Qualified Domain Name while SDK connections will use the simple name for Trust based PI Connections.https://techsupport.osisoft.com/Troubleshooting/KB/KB00865 - Time change issuesWindows domains can have strict time rules that are enforced by the domain controllers. Each member of the domain must be relatively in sync with the domain controllers to prevent authentication related failures. If the PI System Server is added to a new domain it could potentially have its date and time adjusted to match that of the new domain system. If this is new time is significantly different than the previous time it could negatively impact the PI System Server behaviour.http://support.microsoft.com/kb/224799/- GPO behaviourIf the PI System Server is being connected to a new domain then the new domain controllers may enforce Group Policy Objects that were not defined or enforced on the previous domain. Group Policies can affect many aspects of the operating system environment and can therefore affect the behavior of the PI System. For example, a GPO policy may be in effect that will prevent TCP/IP connections on port 5450 and therefore affect the PI System.http://support.microsoft.com/kb/224799/
>Hi Dean, do you have any collective/failover?
Thanks for the info!
Retrieving data ...