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

It's been a while (and many product versions) since I did this myself, but I remember it as just undeploying from one galaxy and then deploying the node in the new galaxy.

If you have different System Management Servers for the old and new galaxies you would need to reconfigure the node to join the Solution Security scope of the new galaxy (i.e. point the node to its new SMS). You would also need to verify that the node uses the same Network Account as the new galaxy, but I can't think of anything needed beyond that. 

I guess there could be some internal mechanism that hasn't disengaged cleanly from the old galaxy, but I suspect you'll need Tech Support help for that unless someone else here has experience to share.

Hi Jakob,

The steps you provided should be sufficient in removing the platform components from your machine so that you can deploy a different platform to it. 

However, I have been on calls where we do these steps, the platform no longer shows in the SMC/OCMC, but the new galaxy still thinks there is a platform deployed there(Just like what you described). To remedy this, we used an older utility called the Platform Remover to 'fully' remove everything. This utility was developed a while back(Before 2014 R2) and was supposed to be replaced by the Platform Manager tab within the SMC, but here we are. 

Utility in action(Ignore the error messages):

This test was done on my 2023 R2 P01 machine running Windows Server 2019. It is unknown to me on if the utility would work on a Windows 11/  Windows Server 2022 machine. From the looks of it, I think the utilities only requirement is to have .NET 3.5 installed.  

My recommendation would be to follow the steps you listed, and if you run into problems afterwards, contact tech support to give the utility a try. I would link it in this forum post, but I think AVEVA marks it as an 'internal use only' utility, and I don't want to get yelled at 

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.