Sage 2020 Locking Users Out

Has anyone else had the issue of Sage 2020 running the the processes and details in task manager but not showing the interface and then locking the PT.LCK file and SUA00021.LCK file on their server? Every morning this happens with our Sage 50 and we have about 20-25 constant users daily. Support hasn't been able to resolve the issue and I'm looking for anyone that can help out.

Parents
  • Just FYI this issue is still occurring as of 2020-07-21 with Sage 50 2020 with SP2 installed. For us it seems we didn't have this issue until SP2 was applied, but that may be just coincidental.

    An RDP user (which I still have to converse with) had SUA00021.LCK open, preventing all users from starting Sage 50. From our dedicated Sage 50 server I closed the open file under Shared Folders and that got the other users back into Sage 50.

    Since it was mentioned, the user account with that lock file isn't used for the daily Sage 50 Automated Backup. In fact the backup was actually successful according to the log.

    The RDP server, running Server 2012 R2, is fully updated with .NET as of the Jan. 2020 roll-up (KB4535104). I just applied the July 2020 roll-up (KB4566519) so we'll have to see if that helped.

    Again I still have to talk to the user to find out if they just closed their RDP session, or if they actually logged out of the session but the server kept it alive but disconnected. I've had users quit out of Sage 50 before and it was still running even though it wasn't showing on the user's desktop. To see this I had to run Task Manager to see it still loaded in memory, which may be the case here with this RDP user.

Reply
  • Just FYI this issue is still occurring as of 2020-07-21 with Sage 50 2020 with SP2 installed. For us it seems we didn't have this issue until SP2 was applied, but that may be just coincidental.

    An RDP user (which I still have to converse with) had SUA00021.LCK open, preventing all users from starting Sage 50. From our dedicated Sage 50 server I closed the open file under Shared Folders and that got the other users back into Sage 50.

    Since it was mentioned, the user account with that lock file isn't used for the daily Sage 50 Automated Backup. In fact the backup was actually successful according to the log.

    The RDP server, running Server 2012 R2, is fully updated with .NET as of the Jan. 2020 roll-up (KB4535104). I just applied the July 2020 roll-up (KB4566519) so we'll have to see if that helped.

    Again I still have to talk to the user to find out if they just closed their RDP session, or if they actually logged out of the session but the server kept it alive but disconnected. I've had users quit out of Sage 50 before and it was still running even though it wasn't showing on the user's desktop. To see this I had to run Task Manager to see it still loaded in memory, which may be the case here with this RDP user.

Children
  • Yup, peachw.exe hangs around after closing the UI. (Sage 2015 > 2020 SP2)

    We have 35 users, most of the time only 20-25 are logged on at the same time.

    We have dealt with Sage shortcomings for years, especially these type of issues to which Golden Diamond most premium Sage support package' support tech's answer is always "uninstall and reinstall" forgetting there are 35 users, meaning 35 desktops + server "install/uninstall" instances.

    Anyhow, what we have found is:

    a) COSESS.dat file gets corrupted (installation counter).

        main error message : "can't use Sage, you have installed on the max number of PCs, blah blah"

        Solution:

        1.- [WORKSTATIONS] Restart all workstations to get rid of (b) and DO NOT log back in until completing the steps below

        2.- [SERVER] Start Sage on the server and log on, and if using smartposting, post all journals.

        3.- [SERVER] Stop actian sql and smartposting (if you use this) services

        4.- [SERVER] Find the cosess.dat file in your company folder and delete it

        5.- [SERVER] Restart the actian sql and smartposting services

        6.- [SERVER] Start Sage

        7.- [SERVER] You should be able to log in, then if using smartposting, check that is running.

        8.- [WORKSTATIONS] Have a couple of users to log into Sage, if no issues, everyone can get back in.

        We do this every other week because dumb routine that counts machines can't count or trashes the dumb cosess.dat file.

        I have a scheduled script on the server that stops the services, deletes the broken file and restarts the services.

       Side effects: on large databases ( +4 GB ), this means Sage will be sluggish for a few hours until the database is fully cached in memory. This is more preferable than having to restart workstations mid-day.

    b) peachw.exe loves to hand around randomly in memory.

         No word from Sage about what causes this, just know that it happens more often than not.

        Solution: Restart every workstation at the end of the day, every day. This might be more complex when using terminal services, but in that case just create a script that kills peachw.exe, and restart actian sql and smartposting services for that session.

    c) Actian v13 manager (w3dbmngr.exe) service can go crazy on the workstations spawning child processes on the server and sending trash network packets to and from the workstations.

        This one, main symptom: Some users are in Sage working just fine, when another user tries to log on, Sage UI wont show up or would freeze before the log in screen appears. If you look at the server task manager > network, you will find that a w3dbmngr.exe process communicating to that user's workstation is generating an obscene amount of traffic and even if you close sage (terminate from task manager of course) on the workstation, the traffic won't stop.

        Solution: restart all the workstations, and keep an eye on the server. do not let anyone log back in until all the child w3dbmngr.exe processes are terminated on the server. Once there is only 1 w3dbmngr process (server's), let some users log back in.

       NOTE: If even 1 of the workstations fails to restart as requested, this whole thing can start again, and everyone will have to restart their workstations all over again. terminating sage on the workstations does no remediate this issue, only a restart on all workstations works.

    Can't wait to see what is broken in the new version (2021.0h.not.again)