The 1 Gray PC on the network is still Gray. Not sure why, I had a look in the logs and found these bits:
in the error log:
I checked the folder and the file does exist.
in the aswMaiSv log:
seems the same as other machines on the network that are succesfully communicating.
I’ve turned off simple filesharing.
I’ve opened up ports [tcp/16111] [tcp/5033] [tcp/16102] and [udp/6000] on the firewall.
File and printer sharing is enabled on the firewall.
I can’t currently think what is causing this. I was able to discover it with the discovery task. I was able to push a net_client install across, yet it won’t communicate with the AMS about it’s status.
Sorry I didn’t get back to you sooner. Hectic day yesterday and the AMS was offline till lunchtime today.
I’ve changed the line to ODBC, and it makes no difference.
BTW FYI The AMS is now XP SP1 as we had to do a repair installation, and I haven’t had time to put Service pack 2 on. All other Workstations are communicating properly.
I pushed the network client installation to the problem PC again successfully, but it still will not communicate.
I deleted it from the dynamic computer groups and re-ran the discovery task, but it’s gone straight back into Computers without agent.
What else can I do?
Also, Chapter 9.6 page 71 at the bottom of the page.
The main global configuration file is \data\avast4.ini. Please note that the managed settings are first read from the [i]avast! Secure Storage[/i] - an encrypted data storage area in the registry key HKEY_LOCAL_MACHINE\Software\ALWIL\Software\avast\4.0\SS. If you want to change a managed key in avast4.ini and have administrative rights to make the change, you must delete the associated entry from Secure Storage before changing the INI value. Otherwise, the key value will be read directly from Secure Storage, and the updated INI value will be ignored.
Would this be having an effect? i.e the change from Database=XML to Database=ODBC is being ignored because of the values set in the Secure Storage?
If so, what value do I delete, or do I delete the entire SS folder from the registry?
27/02/2006 08:47:37 1141030057 SYSTEM 1508 Entry point _dbsInsertTextResult@12 not found in module C:\Program Files\Alwil Software\Avast4\aswSXML.dll.
01/03/2006 10:23:35 1141208615 Kalpna 2288 ASWSIMPLE Application error. Error details: CaswSimpleDlg::SaveParameters() - Initialization of storage functions is wrong!.
01/03/2006 10:23:35 1141208615 Kalpna 2288 ODBC function SQLConfigDataSource() failed. Error description: Could not load the setup or translator library.
Currently the network_client avast icon is claiming 5 providers with 0 running.
I’m going to uninstall it manually from the machine, reboot and re-push it. we’ll see how that goes.
Ok.
I uninstalled the AMS console and the network client from the problem PC, and removed all references to Alwil (and symantec) from the registry and cleared all local temporary folders.
Rebooted, reinstalled the console, then rebooted and pushed the client over the network again.
It started off in ODBC and wouldn’t function, changed the Database to XML in the .ini file and rebooted.
The client is now functioning (5 providers, 5 running) but is still not communicating with the AMS.
I’ve temporarily turned off the Win XP SP2 firewall (we are in managed offices so there is another firewall to the internet anyway) and still nothing.
In the error log:
01/03/2006 11:48:08 1141213688 SYSTEM 1528 Entry point _dbsInsertTextResult@12 not found in module C:\Program Files\Alwil Software\Avast4\aswSXML.dll.
01/03/2006 11:48:18 1141213698 Kalpna 120 During the parsing of C:\Program Files\Alwil Software\Avast4\DATA\avast4.xml XML document, following error occurred: C.
01/03/2006 11:48:26 1141213706 SYSTEM 1492 During the parsing of C:\Program Files\Alwil Software\Avast4\DATA\avast4.xml XML document, following error occurred: C.
01/03/2006 12:29:58 1141216198 SYSTEM 1508 Entry point _dbsInsertTextResult@12 not found in module C:\Program Files\Alwil Software\Avast4\aswSXML.dll.
01/03/2006 12:30:08 1141216208 Kalpna 2040 During the parsing of C:\Program Files\Alwil Software\Avast4\DATA\avast4.xml XML document, following error occurred: C.
01/03/2006 12:30:15 1141216215 SYSTEM 1488 During the parsing of C:\Program Files\Alwil Software\Avast4\DATA\avast4.xml XML document, following error occurred: C.
Strangely from the notice log:
01/03/2006 11:43:15 1141213395 Kalpna 164 User Kalpna logged on - the on-access scanner UI was started.
01/03/2006 11:44:37 1141213477 SYSTEM 1512 The virus database (VPS 0609-0) was automatically updated.
01/03/2006 11:48:18 1141213698 Kalpna 120 User Kalpna logged on - the on-access scanner UI was started.
01/03/2006 12:30:08 1141216208 Kalpna 2040 User Kalpna logged on - the on-access scanner UI was started.
01/03/2006 12:31:26 1141216286 SYSTEM 1488 The virus database (VPS 0609-1) was automatically updated.
It's automatically updated the VPS, I'm presuming that it grabbed the update from the internet, but I can't tell that.
Last thing I can think of to do, is check the servers on the machine, turn on the defaults and see if something has been disabled that affects it.
::edit:: Checked the services, everything installed by default by windows, is in the default state for XP Pro. In fact, it’s one of the laptops that I was experimenting with services on, and that’s working fine.
The XML storage must NOT be used for the agent to work. ODBC storage is required. I.e. if there’s the Database=XML line in the ini file, you need to replace it by Database=ODBC.
Please try updating the ODBC/Jet drivers on the machine. They might be somewhat corrupted.
So if it’s imperative that you don’t use XML, why does it have the option?
I presume it changed to XML when ODBC wasn’t working properly, as all the other clients I have checked have Database=ODBC.
Well, that saved me a Format/reinstall on that machine.
Many Thanks VLK!
Updating the ODBC/Jet drivers fixed it.
So if it's imperative that you don't use XML, why does it have the option?
Well, a (not really good) answer is that the netclient has a shared code base with avast Home/Professional, where the XML storage does make sense.
I presume it changed to XML when ODBC wasn't working properly
Yes… unfortunately (and this holds especially on older OS’s such as NT 4.0 or Win95/98) the default ODBC/Jet drivers are very buggy, and cause a number of problems.
We’re currently working on a yet another storage (a third one) that should overcome the limitations of both of the existing storages and should work flawlessly on all OS’s that avast supports…