I am having a very similar problem, though maybe not quite as severe.  SO Entry takes a consistent 7-9s to appear after clicking on it, whether running Sage on the server or on a workstation.  Other tasks that involve fewer db tables seem to load faster, making it seem as though there is a SQL config problem.  Opening a task and clicking on another app while waiting for it to load will frequently cause it to lock up and have to be killed (after waiting up to 10 minutes).  Printing can take 30s or more.

We have been working our way through the knowledgebase articles ("Slow performance when opening a new task or starting Sage 100..."; "Tips on Improving SQL Server performance") on this issue - checking antivirus/realtime scanning, turning off the Product Enhancement Program, checking printers, running as a service (as admin and not), running an an application (as admin and not) - but no relief so far.

We are running a Hyper-V VM for both the Sage application and the SQL server, since that was recommended by our reseller, but I wonder if the resources on the server are adequate.  4 CPU cores, 64GB of RAM, and a dedicated NIC. 

Have you found anything that helped?

I am still working through the system. Our VM host that's running the sage application is a 20 core Dell server with redundant 10GbE NIC and 96GB of RAM. We have two VM's for our system one for SQL and one for Sage 100 premium. For your system try running sage as an application rather than as a service. We typically have 20-40 users in the system at any time. 

We have a very similar situation as far as users and server resources.  How many cores and how much RAM are you allocating to each VM?  Have you put limits on the memory and/or cores that the SQL server can use?  I've read that it can sometimes starve the OS by grabbing all resources for itself.

We seem to have an authentication issue that cropped up a few days ago, the main symptom of which is that after logon, the launcher will take 20s or so to populate fully (user is locked out until it does), but if they close it and immediately logon again it will come up right away, and then if they continue like that it will alternate between low load time and quick load time.  If the workstation has admin privileges on the domain, this doesn't happen.  Installing the workstation with a mapped drive instead of the UNC seems to also be a fix for this problem, though my understanding is it isn't recommended to install with a mapped drive.

Fixing the auth issue above does not cause launching tasks or running reports to work any faster, however, which is a worse problem.

We are running Sage as an application (running as a service started throwing errors locking users out after the first few logged in).

i seem to be having similar issues. Did any of you find a fix? Or is running as an application a temporary solution? (slow launching menus once you're in)

We found that our 20s delay in opening the launcher was due to the presence of the SOTAMAS90 DSN, which once removed from each workstation fixed the problem.  Our 20s delay in opening Invoice History Inquiry was fixed by running the utility to find broken links and fixing them.  I think our culprits were Memo Attachments for what it's worth.  I would focus on issues dealing with missing resources.  It seems like the software will look for them for about 20s before giving up and moving on.

Another problem we had was a report with a subreport in a location that no longer existed.

thank you for the info. I'll try to remove the SOTAMAS90 DSN. 

Running as an application has always been necessary for us, at 37 users. 

Performance also got significantly better when we finally decided to downgrade to a 2012R2 VM (we were on server 2016).  We did this because nothing else worked - and we tried a lot of things - and our reseller was telling us about another customer of theirs that had moved to Sage 2019 but was still on server 2012 and didn't have the performance issues we were having.  Maybe this was because of some new Microsoft security measures on server 2016?  We had disabled Data Execution Prevention on 2016, and did again on 2012R2, but it didn't seem to make a difference in our case. 

We verified no errant network printers, no antivirus scanning MAS folders, everything in the KB article on slowness problems (I can dig up the URL if needed).