A Message To Our Unlimited MAS 90 and MAS 200 Phone Support Clients:

This tip is only relevant to the Sage MAS 200 version 4+. Please be sure to have a complete system backup prior to making any changes as outlined in this document.

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 runnning the App Server service is running with:

1. The System / LocalSystem account –> it will fail (in this example hang) because by defintion 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 succesfully 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. This is the same exact requirement of Business Alerts service too, btw.

Additional Diagnostic Steps for Connection Errors to Sage MAS 200 Server under v4.xx:

Step 1:
On 4.x change these default settings in the Application Server Configuration.

Clients tab – set Reconnect to None (defaults to Automatic)
Server tab – set KeepAlives to Off (defaults to On)

From this point onward the Reconnect option with the App Server will no longer run into any client/server send/receive communication problems (which is an issue with the interpreter itself as opposed to a MAS 200 issue).

As a result, many error 86s will no longer appear but more importantly system hangs, instability and similar symptoms should reduce.

Step 2:
Now you can still have residual problems with possibly corrupted App Server data files (not MAS data files) because of the original Reconnect settings. This is how you replace the files and the necessarily warnings:
* You must have a backup of the entire \home\lib\_appserv directory first
* Do this procedure carefully! Doing it improperly may render MAS 200 unusable.
* All users must be out of the system, the App Server (service) must be shutdown, and you must not see any pvxwin32.exe running in the server’s Task Manager

1. At the server go to ..\mas90\home and run pvxwin32.exe. Click OK at the message. You will be taken to a ProvideX prompt.
2. In Windows Explorer, go to ..\mas90\home\lib\_appserv folder and rename sessions.pvk and locate.pvk files.
3. Optional step – In Windows Explorer, go to ..\mas90 folder. Turn on Explorer option to view full path in the Address bar. Click on the path in the Address bar and copy it into the clipboard
4. Back at the ProvideX prompt, follow the steps that’s listed in the KB Article “How to move or copy Sage MAS 90 or 200 to a new location”. You are interested specifically in the portion of the instructions that mention the few lines of code that will recreate the .pvk App Server data files. It starts out like this:
myobject= NEW(“sy_installation”)