An oldie but goodie from an Alnoor post many moons ago. This is what I send the IT folks when I ask for a user account to run the Sage service. If they don't follow it TO THE LETTER, weird crap will happen!!!!! Perhaps this may be your issue......
I'm glad you brought that up. Although you may know this yourself already, for the benefit of others, this is a good time to mention some of the requirements for Version 4 MAS 200 as it relates to the account that's run the App Server (formerly Host) service or App Server desktop (formerly known as the stand-alone Host). I'll describe it as if the service was running. This is a VERY important topic as it relates to hanging / stability and applies to the majority of MAS 200 installations of 4.x. This is somewhat lengthy but worth the read.
In Version 4 there are many places, unlike Level 3 where a UNC path is executed from the server itself instead of the client. For example, when adding a new report in Report Manager, or browsing through Data File Display and Maintenance, or using G/L Exchange Wizard to export the output, all of these programs plus many others (but still not the vast majority) execute the UNC path (or whatever path is found) in the workstation's PATH= clause in the [Servers] section of SOTA.INI.
For example, let's say the App Server is configured to use the System account (aka LocalSystem). Let's say at a workstation, the user tries add a new report in report manager and it hangs, and hangs up the whole server in fact (because the pvxwin32.exe process is taking 95% of cpu util.) and everybody complains of slow performance now. What went wrong?
Assume Workstation Setup was installed to c:\program files\best\mas 200\version4\mas90. In the Launcher folder, there is the sota.ini. In the [servers] section there will be at least one line containing the server info. Included in this line is the PATH= cause. It is typically regarded as an ""ODBC path"". Whenever you print a Crystal form or report, this is the path executed at the workstation. In Version 4, this same path, found in the client's SOTA.INI is executed by the app server service account in various places. The point is even though this path may be valid from the workstation it may not be from the server itself, at least not for the service account. Let's say the path is \\myserver\actg\mas200\mas90 and the account running the App Server service is running with:
1. The System / LocalSystem account --> it will fail (in this example hang) because by definition the system account is only aware of the local machine and cannot execute a UNC. The System account CANNOT BE USED IN VERSION 4 ANYMORE.
2. A local machine account from the member server MAS 200 is installed on --> it is subject to failing simply because it is not a domain account. This could happen even with the local Administrator account. The way to know for sure is to logon to the server's desktop as that local machine account. You may need to change a policy to allow an interactive desktop logon but consider it necessary. Now that you're logged as the service account on to the desktop, simply click on Start / Run and type \\myserver\actg\mas200\mas90 and press Enter. Now did a Explorer window appear or did you receive a Windows challenge response. A typical Windows challenge is ""please enter the user name and password to access this network resource"". Sometimes unusual messages appears. Regardless, if any challenge whatsoever appears here, it means the app server service is also running into the challenge and instead of presenting you with a UI to let you know you're being challenged, you get hanging or some type of error message instead. You MUST configure it so you are never challenged.
Now lets say you are not challenged and an Explorer window appears after executing the UNC. You're not out of the woods yet. Rt-click,choose New Shortcut. If the shortcut wizard appears, good news - just cancel out. You have now just written a file and deleted a file successfully via the UNC and you should be good to go. If an ""access denied"" message appears, then you have permissions problems to take care of.
3. A domain account that is part of the Local Administrators group --> you have the best chance of success of not running into a Windows challenge response. You have done yourself a great favor! You still need to interactively logon to the server's desktop with the domain account and do the UNC test above but your chances are good unless you have multiple domains and then you have to worry about the trusting/trusted domain relationship.
The moral of the story is in Version 4.x MAS 200, for the App Server service (or App Server desktop application) use a Domain account that is part of the Local Administrators group to ensure your best chances of success (and this login cannot be a service account only). This is the same exact requirement of Business Alerts service too, btw.