Decommissioning and Transferring (OMI) visualization nodes/platforms between Galaxies on same network

Hi Jacob, 
As Rickard and Adam suggests there are some things to keep your eye open for, but in general a successful un-deploy of the client should be sufficient and as long as the Network Account is up to date and the System Management Server is aligned before you deploy the new galaxy you should be fine.

A successful undeploy should not require you to go to step 2 and remove it in platform manager, if its still there, something has gone wrong with your undeploy.

It is in some conditions where the Platform is not undeployed correctly that manual steps are required.

Original galaxy machines (all other platforms) also need to be aware of the un-deploy of this machine so they do not try to reach it in in the assumption that it still exists in the original galaxy with the warnings Platform xxx could not be reached as a result.

This is also managed in a normal undeploy scenario but if something fails this might be an issue down the line especially if they are on the same network and the nodename stays the same.

The Platform Remover (aka. Platform Killer) utility was in recent versions moved to the OCMC, but is only available locally, that means you have to run it from OCMC on that client node. Do not try this from the GR Node.
In OCMC, it will remove the Local platform only.

A thing to be aware of regarding the platform removal from OCMC is that its slow!
It will prompt that its completed quite quickly, but some things are still happening in the background that you could verify in Log Viewer, if you reboot before its fully completed, then the platform is not completely removed and you could end up in a bad state.

Platform remove is available if your node detects a running platform.

The official statement from AVEVA regarding the legacy stand-alone version of Platform remover Utility is not to use it on newer versions of System Platform since some things have changed in the environment that the (old) utility is not aware of.

But if all fails it can not hurt to try it.

There is one thing that recently popped up on my radar, due to some issue we have detected, that is the PCS configuration.

We have seen that the previous galaxy was not removed from the PCS Services, this means that they were still running on a client even though a new galaxy with a different name was deployed.

As you can see in the above example, I have a set of services related to two different galaxies in my system.

The working theory at the moment is that this could cause unnecessary chatter on the network, having that older service trying to reach the old galaxy from a client machine (or object server).

Unfortunately this is not verified or any official statement on how to resolve this from Aveva, since the issue is ongoing, but we know performing a complete uninstall (and cleaning config files) and re-installing PCS among other things will clean up the services. but re-installing an existing machine comes with another set of challenges.  as you might be aware of.

This is as far as I know, only effecting OMI and perhaps some other components that utilizes PCS, InTouch does not use PCS yet and should not be affected by this.

There is also a quicker way to clean PCS Services if re-install is not possible, that requires some editing ServiceDeploymentPackage.config-file and restart of the ArchestrA  Agent (Watchdog) service, but since it is an ongoing issue can not say this is the correct method either.
So if this is a production critical system I advice you to contact techsupport before performing any modifications!

I'm mentioning this only because we have that active ticket (against 2023 R2 P01) related to this scenario and will update as soon as we know more for certainty.

We do not know fully the effects of having these old services, but we have confirmed that they are at least creating delays in communication with the "correct" galaxy, in scenarios where we have a lot of data to be retrieved on screen, on a OMI client.

If anyone else has some insights on the PCS issue I am happy to discuss it, but here official information from Aveva is needed if you are to dig deeper in to this.

Hi Jacob, 
As Rickard and Adam suggests there are some things to keep your eye open for, but in general a successful un-deploy of the client should be sufficient and as long as the Network Account is up to date and the System Management Server is aligned before you deploy the new galaxy you should be fine.

A successful undeploy should not require you to go to step 2 and remove it in platform manager, if its still there, something has gone wrong with your undeploy.

It is in some conditions where the Platform is not undeployed correctly that manual steps are required.

Original galaxy machines (all other platforms) also need to be aware of the un-deploy of this machine so they do not try to reach it in in the assumption that it still exists in the original galaxy with the warnings Platform xxx could not be reached as a result.

This is also managed in a normal undeploy scenario but if something fails this might be an issue down the line especially if they are on the same network and the nodename stays the same.

The Platform Remover (aka. Platform Killer) utility was in recent versions moved to the OCMC, but is only available locally, that means you have to run it from OCMC on that client node. Do not try this from the GR Node.
In OCMC, it will remove the Local platform only.

A thing to be aware of regarding the platform removal from OCMC is that its slow!
It will prompt that its completed quite quickly, but some things are still happening in the background that you could verify in Log Viewer, if you reboot before its fully completed, then the platform is not completely removed and you could end up in a bad state.

Platform remove is available if your node detects a running platform.

The official statement from AVEVA regarding the legacy stand-alone version of Platform remover Utility is not to use it on newer versions of System Platform since some things have changed in the environment that the (old) utility is not aware of.

But if all fails it can not hurt to try it.

There is one thing that recently popped up on my radar, due to some issue we have detected, that is the PCS configuration.

We have seen that the previous galaxy was not removed from the PCS Services, this means that they were still running on a client even though a new galaxy with a different name was deployed.

As you can see in the above example, I have a set of services related to two different galaxies in my system.

The working theory at the moment is that this could cause unnecessary chatter on the network, having that older service trying to reach the old galaxy from a client machine (or object server).

Unfortunately this is not verified or any official statement on how to resolve this from Aveva, since the issue is ongoing, but we know performing a complete uninstall (and cleaning config files) and re-installing PCS among other things will clean up the services. but re-installing an existing machine comes with another set of challenges.  as you might be aware of.

This is as far as I know, only effecting OMI and perhaps some other components that utilizes PCS, InTouch does not use PCS yet and should not be affected by this.

There is also a quicker way to clean PCS Services if re-install is not possible, that requires some editing ServiceDeploymentPackage.config-file and restart of the ArchestrA  Agent (Watchdog) service, but since it is an ongoing issue can not say this is the correct method either.
So if this is a production critical system I advice you to contact techsupport before performing any modifications!

I'm mentioning this only because we have that active ticket (against 2023 R2 P01) related to this scenario and will update as soon as we know more for certainty.

We do not know fully the effects of having these old services, but we have confirmed that they are at least creating delays in communication with the "correct" galaxy, in scenarios where we have a lot of data to be retrieved on screen, on a OMI client.

If anyone else has some insights on the PCS issue I am happy to discuss it, but here official information from Aveva is needed if you are to dig deeper in to this.