• Replies 2 replies
  • Subscribers 582 subscribers
  • Views 606 views
  • Users 0 members are here
Options
Related

Citect Default Server Password Retrieval ...

Gordon

Hi All,

I have a need to try and retrieve a default server password from a v720SP4 live site system. The password has not apparently been documented by others, and at present replacing the password used by the live site system is too risky.

The password is recorded in the ~\Citect\Config\CitectSCADAAuth.bin file. I have the file, and I also have an independent v720SP4 environment available in which to test.

Citect/AVEVA Support suggests that the CitectSCADAAuth.bin file cannot simply be copied across from one server to another. However, I can confirm that there is no apparent issue with copying the file from (say) a primary to a standby server of the same 'site' installation, if you so wish.

Unfortunately, I have not been able to successfully use the 'site'-based file in an independent v720SP4 test environment. This suggests that something other than a password is contained within the file. Does anyone have any details of what else may be contained in the file ?

Is anyone aware of any tools that may be floating around to assist with retrieval of the password ?

Thanks in advance.

Parents

  • In reply to your private message, I don't know how else to avoid the server password. I would suggest disabling the password on each client as I mentioned. Then when you get ready to start the new servers you'll have to reset the password on the old servers and restart them. The interruption will be minimal, assuming you only have 2 servers.

    I would also verify on test computers that the new version will communicate with the old version if you have the correct password. I'm not sure how far back it will go, even if you set the [LAN]EarliestLegacyVersion parameter.

    Another consideration is whether commissioning is valid if you're relying on the old servers for all I/O data. When I've done side-by-side upgrades I've always used the new I/O servers for the new clients/servers, and if there's a bandwidth limitation I've sometimes slowed down the communications on the servers that aren't being used by plant operators (increased I/O Device cache times or longer periods for scheduled devices). For devices that can't handle multiple simultaneous connections, you could use the [IOServer]WatchDog parameter on both the old and the new system to keep the standby server from connecting to the device to test communications when the primary server is also connected. 

Reply

  • In reply to your private message, I don't know how else to avoid the server password. I would suggest disabling the password on each client as I mentioned. Then when you get ready to start the new servers you'll have to reset the password on the old servers and restart them. The interruption will be minimal, assuming you only have 2 servers.

    I would also verify on test computers that the new version will communicate with the old version if you have the correct password. I'm not sure how far back it will go, even if you set the [LAN]EarliestLegacyVersion parameter.

    Another consideration is whether commissioning is valid if you're relying on the old servers for all I/O data. When I've done side-by-side upgrades I've always used the new I/O servers for the new clients/servers, and if there's a bandwidth limitation I've sometimes slowed down the communications on the servers that aren't being used by plant operators (increased I/O Device cache times or longer periods for scheduled devices). For devices that can't handle multiple simultaneous connections, you could use the [IOServer]WatchDog parameter on both the old and the new system to keep the standby server from connecting to the device to test communications when the primary server is also connected. 

Children
No Data
© 2025 AVEVA Group Limited or its subsidiaries. All Rights Reserved.