Sage 100

Client is on MAS200 4.40. Local workstations, no terminal server. Generally run workstation setup with server name. She is randomly (every few days to every other week) getting a 'No Valid Servers Found'. She'll run WKsetup and is good again for awhile. Last week Thurs I logged in after she received the error and found the Sota.ini is getting wiped out. All that's left is the attached picture. She had several workstation setups in add/remove programs, so uninstalled all, rebooted, started all over using server name. She emailed today that it happened again. Found Sota.ini is wiped out again. Uninstalled wksetup, installed with IP and we'll see how this goes. I did notice McAfee (on the local machine) was not set to exclude the C:\Sage Software so am requesting this, and local firewall is turned off. At a loss as to what would wipe out the Sota.ini. I did check to be sure I could ping the server by name and IP, and able to ping workstation from server (a suggestion from Sage City). They have 15 users and I think she is the only one getting this. Another Sage City suggestion was network cable/connections. Would a bad connection wipe out the Sota.ini information? That seems bizarre! Server: W2008 R2, 64 bit. Workstation: W7 Pro SP1, 64 bit 4 gb Ram. Help!

Is there a sota.tmp in the folder with the correct info?

I saw a sota.tmp but didn't look in it. What info should be in it?

I was wrong, no sota.tmp, but I have a sotachr.ini & sotapgm.ini in the launcher folder

My money is on either anti-virus or anti-malware scanner picking this file up and blocking it somehow. Naturally the customer won't have a clue about how to maintain their AV and in their second breath will tell you that it never could be the AV because ""Microsoft Office runs just fine"".

I just ran into this on a 2013 Standard to 2018 Advanced. Oddly it happened on both the server (where I had a workstation setup) and the Terminal Server stations. It appeared that the sota.ini at some point was renamed sota.tmp on the TS workstations On the server I uninstalled and reinstalled the workstation that fixed the issue on the server On the TS I renamed sota.tmp to sota.ini and that fixed the issue We were in the process of installing a minor Starship upgrade to the latest release by using their web update. At present I suspect the install routine for Starship but will keep an eye out for recurrence. I can't rule out some type of anti-virus/anti-malware.

Hmm.. I just ran into it again over the weekend on the server with v2016 Adv. Server client worked fine on Saturday, 'No Valid Servers' message on Sunday. Ended up renaming the sy_workstation, sy_console, Locate.pvk and Sessions.pvk and it worked. Not the same client as above though. Didn't check the Sota.Ini.

Just yesterday. WIN 7 WS. v2017 ADV Uninstalled workstation, reinstalled. Was working last night when I dropped the connection.

Problem came back again. This is the only customer notifying me of the ""no valid servers"" and since we were not installing anything today I will now focus on anti-virus / malware as the most likely culprit. This is an upgraded 2018.3 Advanced (coming from 2013 std)

On the TS when I look into \sage\sage 100 workstation\mas90\launcher this time I have a sota.ini but it has only one line showing the last position of the window. Something appears to be deleting the sota.ini then when someone goes in if there isn't an INI it must recreate? Anyone else seen this and have a suggestion other than the AV/Malware?

I have seen this before and it was AV. I think Webroot in my case

Guess what AV is in use here... Webroot!

They are excluding Sage folders from Webroot. Will post back if I have further issues/updates.

This is still an ongoing issue where the main symptom is they get a ""No Valid Servers"" then their sota.ini is blank except for one line as posted by Nancy. They work around this by copying back the SOTA.INI and it works fine. Until the next time. I have no other customers experiencing this and aside from this message thread it's not on my radar as a bug/issue at all. I suspect that the customer doesn't know how to exclude files or advanced scanning (they use WebRoot A/V) and is very frustrated at the recurring issue.

Wayne 2 things come to mind: 1) Are they excluding the Sage file extensions from WebRoot where Wkstn Setup was run on the TS (that local \mas90 folder as well) OR just from the Sage server's \mas90 folder? 2) When you look under the hood, the nature of how SOTA.INI is updated today as a user logs in is still like it was in v3.20 --> not AV or o/s friendly. Besides A/V it is DEP unfriendly too. IOW client's IT can either follow the Sage KB article for turning off DEP right on the TS **OR** keep it enabled but add every EXE file under this location as a DEP exception: c:\sage\sage 100 workstation\mas90\launcher