From the way back machine (Besttalk forum days). A post from Alnoor.
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.
Additional Settings for App Server v4
There are 2 settings in App Server Config you want to adjust. One is on the Server tab and is called KeepAlives. Uncheck it. The 2nd is on the Clients tab called Reconnect. Set it from Automatic to None. (v2019 None is default setting)Do this with all users out of the system.
------------------------------
Jeff Schwenk
Bottomline Software, Inc.
(540) 221-4444
------------------------------
Original Message:
Sent: 11-01-2022 11:25
From: Wayne Schulz
Subject: StarShip Cloud and Sage 100 SQL setup issue
Do either of you have a document that you share with the IT departments with specific rights that the service should have?
In many cases Sage ( and others ) take the "lazy" way out and suggest that the service account have more permissions than is required.
I've also run into this with the SA account for SQL - almost no formal IT department is giving that password out.
And when you go to look at the Administrator Guide for Sage 100 -- which BTW looks like it was last updated around the time of Y2K --- there is frequently no concise list of the EXACT role that an account needs - either for running aservice or attaching to SQL during install/upgrade.
------------------------------
Wayne Schulz
wayne@s-consult.com
https://www.schulzsays.com/
Schulz Consulting
(860) 516-8990
Moodus, CT
------------------------------
Original Message:
Sent: 11-01-2022 09:37
From: Jeff Schwenk
Subject: StarShip Cloud and Sage 100 SQL setup issue
Very much agree @Wayne Schulz FWIW, if they are using ADV or SQL, they already have the Sage service user running as a domain admin so Starship could use that service account.
------------------------------
Jeff Schwenk
Bottomline Software, Inc.
(540) 221-4444
Original Message:
Sent: 11-01-2022 08:55
From: Wayne Schulz
Subject: StarShip Cloud and Sage 100 SQL setup issue
First, thanks for both of you for following up on this so that future searches find the resolution.
Secondly, adding a Domain Administrator as the service user is something that many of my sophisticated IT departments will push back on. And, in my view, we are going to see more pushback as the small Sage 100 customers are squeeze out either because they go out-of-business or get acquired. And what's left are the larger Sage 100 customers who either have sophisticated IT departments or are using a sophisticate MSP.
------------------------------
Wayne Schulz
wayne@s-consult.com
Schulz Consulting
(860) 516-8990
Moodus, CT
Original Message:
Sent: 10-31-2022 17:48
From: Bernie Lehman
Subject: StarShip Cloud and Sage 100 SQL setup issue
dI worked with StarShip and followed these steps to get the connection to work with Sage 2022 SQL
1. StarShip Service user has to be a domain administrator
2. Signed in to the server hosting StarShip as the user running the service
3. Open Sage 100 SQL with any user
4. Open the StarShip web application
5. Delete the existing company
6. Create a new company using the connector on the new server
Thanks again @David Speck II for your help yesterday!
------------------------------
Bernie Lehman
Partner
Lehman Wesley & Associates