14 Ottobre 2021 alle 15:07 #146971FMoriggiPartecipante
Hi, I need to share user accounts between a Movicon 11.6 project, running as a Windows service on a virtual server, and three Movicon 11.6 client projects, running on three different physical computers connected to the same network.
I’ve shared the folder with the .rtusers and .rtusers_ files of the server and set the full network path (\\pifms\utenze\srv_am1208.rtusers) in the property “Runtime User Files” of each client project.
User management from any remote client (login, creation, deletion, editing) works fine for days, sometimes weeks, projects can be closed, computers restarted many times, until something suddendly causes the deletion of both the files in the shared directory and no user is allowed to log in the software anymore, anywhere.
The only solution I have found so far is to manually recreate those files in the shared directory or restore them from a previous backup file but this can’t be accepted in a production environment.
It seems to me that something deletes the files when a client project shuts down but there is no custom code that addresses such files in our Movicon projects and there is nothing in Windows set to automatically delete files on a network share (also, there is no trace in any log about this).
Has any of you ever experienced anything similar before or has any suggestion on what could I check or do to prevent Movicon(?) from deleting those files?
Thanks to whoever could help,
Fabio18 Ottobre 2021 alle 16:21 #146982MODERATORAmministratore del forum
Very strange and anomalous behavior.
Reading the email makes me think of a particular problem in your infrastructure, a network loss in case the file is edited or saved could compromise it but I don’t think delete it.
Can you reproduce the problem with a test environment?
Check if you are running with admin right on al the Movicon instances
When the runtime user file is placed in a network path, the folder in which this file has been saved must be enabled to access various clients. In addition, when projects run in a machine outside the domain, the “.uxp” file in which Movicon saves modified passwords, must be enabled with anonymous access.
Best Regards19 Ottobre 2021 alle 10:52 #146994FMoriggiPartecipante
Hello and thank you for your reply.
The system is installed at a customer site so I have little if no control on the IT configuration, internal domain policies and rules.
We’re using that same architecture in different customer sites so far and, except a similar problem caused by a bug in a past build of Movicon 11.5 (solved by updating it from version 1181 to 1185.1), they all work smoothly, though this is the first 11.6.1203 we have used.
I confirm all movicon executables are running as administrator, everywhere, and so far there is no limitation for the shared folder permissions. I tried to set a ‘Deny Delete’ rule on the .rtusers file properties but it gets deleted anyway and, as being in a network share, the file doesn’t appear in any windows recycle bin.
Users are logging in Movicon using their domain accounts, so there are no passwords stored in the system and I didn’t see any ‘.uxp’ file so far.
I tried to recreate the problem in a test environment and also at the customer site but, of course, it never happened under my sight.
Plus, I did set the same shared path in the ‘Network user Path’ property of the projects (under Project Path Settings), thinking to get some logging from the clients but still, no log file was ever written (i know it sounds silly but… could it be that this logging property empties the folder from time to time?).
Yesterday I’ve set a trace in the local policies of the operative system of the server, to track whatever changes the content or the properties of the files in the shared folder, then restored the files from the latest backup. I saw this working, catching manual deletion of the files and user data changes from the Movicon User Editor programs of all the clients so, it seems now I only have to wait for the issue to happen again (patiently waiting behind a bush 😉 )
- Devi essere connesso per rispondere a questo topic.