Hey John, I'm curious...

how many days past before you need to reboot?

how many users?

whats the company's folder size?

I have experienced something somewhat similar.

We do not use terminal services.

We have a 40-user Sage50 Quantum installation on a dedicated WS2012 R2.

Out database is about 3 GB.

After quite a few of these log-in freezes, I ended up having to reboot our server every week and having the users to reboot their machines every day at the end of the day to kill any lingering open sessions to Sage. Sometimes Sage is still open, even when the application is not visible on the taskbar, the sneaky peachw.exe is still running. You would not know until you open Sage again and notice it goes straight to the main screen without asking to log in or when you try to reboot and windows tells you that peachw.exe is preventing windows from restarting. That is why a reboot is the only way to kill peachw.exe, smartposting and w3dbsmgr.exe.

There seems to be a memory leak w3dbsmgr.exe, because the longer you keep the machine up, the more memory that process takes. A reboot is the only thing that has dramatically reduce the number of instances of this type of issue.

Another unlikely cause is the calling-home or licensing check Sage50 would do when logging in. I have not seen that issue in a few months, perhaps that license check is not performed anymore or at least not in the same way now on  2017.1 or 2017.2, but when it used to happen, this was the very same behavior. Logging in would take up to 5 minutes, users already logged on would not experience any slowdowns, but if they logged out and tried to log back in, they would experience a long wait before Sage would respond. No errors whatsoever, just a (not responding) text on the application title bar.

Anyhow, perhaps a script to restart the smartposting and the w3dbsmgr.exe services over the weekend may make rebooting the server unnecessary.

The only side effect is that the first user that logs in on Monday may be greeted with a Sage error (if smartporsting or w3dbsmgr.exe fail to restart with the script) or a lethargic performance until the Sage's memory cache is repopulated.

I hope you find a better solution.

Hey John, I'm curious...

how many days past before you need to reboot?

how many users?

whats the company's folder size?

I have experienced something somewhat similar.

We do not use terminal services.

We have a 40-user Sage50 Quantum installation on a dedicated WS2012 R2.

Out database is about 3 GB.

After quite a few of these log-in freezes, I ended up having to reboot our server every week and having the users to reboot their machines every day at the end of the day to kill any lingering open sessions to Sage. Sometimes Sage is still open, even when the application is not visible on the taskbar, the sneaky peachw.exe is still running. You would not know until you open Sage again and notice it goes straight to the main screen without asking to log in or when you try to reboot and windows tells you that peachw.exe is preventing windows from restarting. That is why a reboot is the only way to kill peachw.exe, smartposting and w3dbsmgr.exe.

There seems to be a memory leak w3dbsmgr.exe, because the longer you keep the machine up, the more memory that process takes. A reboot is the only thing that has dramatically reduce the number of instances of this type of issue.

Another unlikely cause is the calling-home or licensing check Sage50 would do when logging in. I have not seen that issue in a few months, perhaps that license check is not performed anymore or at least not in the same way now on  2017.1 or 2017.2, but when it used to happen, this was the very same behavior. Logging in would take up to 5 minutes, users already logged on would not experience any slowdowns, but if they logged out and tried to log back in, they would experience a long wait before Sage would respond. No errors whatsoever, just a (not responding) text on the application title bar.

Anyhow, perhaps a script to restart the smartposting and the w3dbsmgr.exe services over the weekend may make rebooting the server unnecessary.

The only side effect is that the first user that logs in on Monday may be greeted with a Sage error (if smartporsting or w3dbsmgr.exe fail to restart with the script) or a lethargic performance until the Sage's memory cache is repopulated.

I hope you find a better solution.