Plant SCADA 2023 R2 (U1), Deployment Server Process won't start, or will start slowly, or only deploy once.

Been having problems with a new (updated) install of PlantSCADA. 20 clients, redundant server, on a domain.

Configured deployment server on development machine. Deployment logs in, creates a deployment and allows deployment to clients and servers, and mostly crashes mid way through deployment (although appears to complete) and then can never deploy again.

Updated to Update 1 with same results. Have tried multiple options (with/without encryption, win11 development machine and server 2016 development machine, move SMS machine, etc no changes.)

Client authenticates to server correctly. SMS, and licensing are on a separate machine. Standard ports.

You can create deployments and deploy once (when lucky) otherwise the process either stops or stops responding. Services says its running, but studio gets stuck in 'refreshing' for computers and versions. Restart the computer and about 50% of the time it starts straight away. The other half the service never starts, just get stuck at 'starting'.

Any ideas welcome.

Parents
  • Hi  ,

    Sorry to hear you are having problems with the Deployment feature.

    It is great that you upgraded to Update 1, as this did have a number of quality improvements:

    Deployment

    2864853 - Deployment activity keeps refreshing when using a domain user

    The deployment authorisation logic has been simplified to improve performance and correct a token timeout calculation that would cause constant refreshing.

    3047818 - Deployment status disappears from the deployment server Computers view

    During deployment of large projects, if the deployment operation went beyond a user session timeout interval it would not be successful due to the user session becoming unauthorized. Now when a deployment operation commences, it will remain active even after the user session expires.

    2968800 - Target and Profile columns on the Computers view occasionally revert to their previous values

    A background operation to refresh the Computers view of the Deployment screen will now be suppressed after the Target or Profile dropdown control has been pressed. The background operation will be restored when the process completes.

    3290142 - Deployment Server password unable to contain double quotes and semi-colon characters

    The Deployment Server has been updated to permit passwords containing double quote and semi-colon characters.

    Can you tell me a little about your project? Does your system have access to the Internet or DNS servers?

    There have been previous issues where customer systems that had trouble contacting DNS, would cause delays.

    I would recommend reaching out to AVEVA Customer Support and log a ticket with them to have this investigated further. I believe they will have a solution for you if it is related to DNS recursion. Quote issue number 3288728.

    Also, before contacting Support, try collate the following information:

    - Operations Control Management Console (Log Viewer) to see if any errors are reported on the Deployment Server?

    - Windows Event Viewer.

    - Logs folder, for the tracelog.SE.Asb.Deployment.Server.WindowsServer.dat file

    Kind regards

    Olivier

  • Hi Oliver,

    I spotted that U1 resolved some issues but doesn't seem to have made any difference.

    I can tell you a bit about the project:

    The system has no access to the internet. It uses local DNS servers for name resolution and a local AD.

    I am aware of the DNS recursion issue, and we have now tried with the DNS recursion on/off/NoNetworkTime variable set.

    Unfortunately this made no difference.

    In the process, however, we were collecting log files and noticed that the deployment server log file had information about repeated throwing exceptions "The remote name could not be resolved: 'computername'" (Computername used instead of actual name) yet all computers could be found by name on the network.

    We copied the log file out and went to delete the ones in the folder and it wouldn't let us.

    We stopped the deployment service and then deleted the log file.

    Turned the service back on and haven't had a problem since. No further entries have been made (outside of normal startup) to the log.

    The deployment server is operating normally.

    Maybe something happened with the log file? Will keep an eye and follow up soon.

    Cheers for your reply.

  • Hi  ,

    Thanks for the update. Definitely sounds like a gremlin in the system was causing an issue. I am not sure why the logging would cause an issue with the Deployment Server. It is more likely the act of restarting the service got it out of the bad state.

    Keep an eye on it and hopefully it is more reliable going forward.

    Kind regards

    Olivier

  • Hi Oliver,

    I completely agree that the service restart is the fix there, but previously it would never allow us to start the service... and if it did it would only work for a short time. Once the log file was deleted and the service restarted it behaved normally.

    Keeping an eye on it, and keeping an eye on what it puts in the log file. If there is any further updates I'll post.

    Thanks for your response.

  • Hi  , we are having a similar sounding problem, but are already at update 2 and I have deleted the log files (there were some weird errors in there) - now I just have an error that my engineering machine where the deployment client is running is offline (which it's not) and when I go onto that machine and try to view computers or versions the requested operation pretty much always times out.  Just wondered if any of this resonates with you and if I am missing some critical step(s)

    I look forward to hearing from you, 

  • Stuart, deployment server still gives us grief at times.

    We have found: SMS choice makes a huge difference. We found it works best when the SMS is NOT a server nor a client to the deployment system.

    For whatever reason, name resolution is still a problem from time to time. We are using older domain servers (2012 I think?) and we suspect this may be part of the problem, however can't verify. Log files fill up with "cant connect to COMPUTERNAME" when the DNS is having problems, and they fill up with "can't connect to 192.168.73.23" when it's operating normally. Restart your DNS server, then restart your deployment server and delete the logs again, check if it showing up with name or IP. if its still name in the log files, try again?

    Security - create a god user and add them to all PlantSCADA roles, log everyone else out and log in as god on deployment server and client.

    Firewall - Plant SCADA says it modifies the firewall, but for some reason on ours it did not add the domain network to the firewall rules - check.

    If you are using the new fancy pants licensing - put your license server and license manager on a separate computer to your deployment server. Port 443 is in hot contention.

    I'd be interested to hear how you go.

  • If your domain controllers are not reliably reachable, you may need to create a hosts file on the servers and clients so they can reach each other for deploying projects.

    Edit C:\Windows\system32\drivers\etc\hosts file in Notepad (you may need to run Notepad as administrator). Add the names and IP addresses of each server and client. Save the file with no extension. Copy the file to each server/client so they can all find each other.

  • Thanks Eric, this seems like an odd and disappointing thing to need to do in 2024.  Our system should not have any such issues as it is all running on one VM host right now, but if it is having some communication issues, I would like to get to the bottom of those as it may well be impacting on other things.

  • Thanks Dominic.  Our customer is a bit old school with licensing, so hopefully that's not an issue for us.

    I am not sure what you  mean about the SMS.  Do you mean it needs to be on the same machine or ....?

    The main symptom I am seeing is that everything is slow to start, and presumably respond, eg this morning, the configurator started taking 3-4 mins to start!

    Is your god user a domain user?

Reply
  • Thanks Dominic.  Our customer is a bit old school with licensing, so hopefully that's not an issue for us.

    I am not sure what you  mean about the SMS.  Do you mean it needs to be on the same machine or ....?

    The main symptom I am seeing is that everything is slow to start, and presumably respond, eg this morning, the configurator started taking 3-4 mins to start!

    Is your god user a domain user?

Children
  • Stuart,

    We got the best performance with the system management server as a separate machine on the domain. I think Schneider recommend this but we did try having the SMS the same as the HMI server and the same as the license manager.

    Yes, our god is a domain user. We also noted that the file permissions that Schneider set during the install should be domain tied, so join your computer to the domain FIRST, then install plantscada.

    Our DNS issue had more to do with the DNS server net stack falling over. It didn't change the fact that the deployment server couldn't connect and was pushing items into the log. The log changed from names that couldn't be found, to IPs that couldn't be found. Can't recommend a lmhost file as I would not be the first person to forget about it and have weird things happen when IPs change, if you can't get to the DNS then hosts file will be your only option.

    Configurator slow to start is a common issue. Still happens to us periodically. seems to be first restart. That might be worth another thread.

  • Thanks Dominic, the SMS and deployment server are the only things on that server.  They did have a few more unnecessary components installed on it, but not configured, so I remedied that, to no avail unfortunately.  That process should have installed everything with the pertinent domain groups etc I would have thought, so I am still a bit stuck.