Step by step guide for transferring Historian data to a new historian server.

There is a Tech Note (see Article 000034301) published with more complete instructions. Though Historian 2023 R2 isn't mentioned in the Tech Note, the same steps still apply. Using the SQL database backup/restore is generally better as there is some information missing in the CSV-based export/import (e.g. tag groups, annotations, and Historian Client Web charts). It is included in those instructions, but there are few aspects that might be missed in your steps above:

1. If the old/new server names are different, you'll need to tweak a few more things
2. If you use the database backup/restore, use the Configurator to migrate the old database schema to the new one

Hi Elliott, thank you for your help.

managed to figure the transfer out. 

Just to explain before I hit you with a follow up question.

What I have now is two identical systems running the same galaxy structure. 

old system SP v.20 and new system SP v.23 , both are on the same network but run independently of each other. 

No SMS activated (will configure it when old system is removed, to avoid conflict between the old and new system)

Instead if transferring the runtime database from the old system, I recreated it on the new server through deployment to the new historian, ( I could because it consists of the same tag names) I could then copy the history blocks from the old system.

Final step to be able to query the data was copying certain files from the old historian support folder into the newest history block on the new historian server. 

Both installations are running on the same Domain network all the same users and everything user access related the same. The admin account I used to install everything is the same.

We use windows integrated login for all users that connect to the SQL database when adding a historian server in the historian client.

What now remains and I have not been able to figure out...... 

I need the SCADA users to be able to add the new historian server when they run the historian client.

They are able to add the old historian server but not the new. 

The "main" system platform admin account i use for installation and service works fine but not any others.

I am pretty sure it has to do with the historian security settings in the configurator. Tried adding one user to test,  but it doesn't change anything.

Any help would be appreciated! 

regards

Jakob

Hi Elliott, thank you for your help.

managed to figure the transfer out. 

Just to explain before I hit you with a follow up question.

What I have now is two identical systems running the same galaxy structure. 

old system SP v.20 and new system SP v.23 , both are on the same network but run independently of each other. 

No SMS activated (will configure it when old system is removed, to avoid conflict between the old and new system)

Instead if transferring the runtime database from the old system, I recreated it on the new server through deployment to the new historian, ( I could because it consists of the same tag names) I could then copy the history blocks from the old system.

Final step to be able to query the data was copying certain files from the old historian support folder into the newest history block on the new historian server. 

Both installations are running on the same Domain network all the same users and everything user access related the same. The admin account I used to install everything is the same.

We use windows integrated login for all users that connect to the SQL database when adding a historian server in the historian client.

What now remains and I have not been able to figure out...... 

I need the SCADA users to be able to add the new historian server when they run the historian client.

They are able to add the old historian server but not the new. 

The "main" system platform admin account i use for installation and service works fine but not any others.

I am pretty sure it has to do with the historian security settings in the configurator. Tried adding one user to test,  but it doesn't change anything.

Any help would be appreciated! 

regards

Jakob

Sounds like the security change to add the one user wasn't picked up. That could be because the security is based on membership in a local Windows group and those are only refreshed upon a new login--if there is a cached login from before the change, that won't pick up the new group membership (a Windows "feature").

If you know the only login is RDP, for example, you can "Logout" that session (not "Disconnect"), but there can be file share access and other cached logins that are harder to find and logout. The only guaranteed way to clear that cache and ensure all the current group memberships are applied is to reboot the Historian node.

ok, will try that,

Do I understand correctly that when a user is added to the historian security list in the configurator on the historian node. It adds the user to a local windows group that has the access needed.?

Yes. You can accomplish the same result using the standard Windows MMC snap-in (and other tools) for managing users, but the panel in the Configurator aims to simplify that experience. There are well-known groups for "aaAdministrators", "aaPowerUsers" and "aaUsers" with different rights. You can read more about those in the administrator docs. 

ok will do, thank you very much for your help.

regards

Jakob