Avast WEBforum
Business Products => Archive (Legacy) => Avast Business => USA Education Products => Topic started by: REDACTED on February 10, 2015, 05:30:18 PM
-
We're experiencing a strange problem with remote assistance not working for some clients - see attached for the error message we are receiving. We are running client version 8.0.1603.
As stated above, the problem only affects some clients. After Wiresharking clients that are working and ones that aren't, we've been able to narrow down the difference to a resolved IP address for rh.ara.avast.com. The clients that aren't working are resolving to 77.234.41.84, while the clients that do work resolve to 77.234.44.84. I'm not certain if this has anything to do with it, but it was the only difference we saw. We also connected a few machines that weren't working to an open offsite internet connection to eliminate any content filtering/local network issues, but the problem remained. I have the Wireshark files available by request - thank you.
-
Unless you have a support contract with Avast! or whoever provides the paid support, I'm going to suggest you implement a workaround until the problem is resolved. More than likely, one group of remote help servers is having issues with it's configuration or is unreachable.
In your DNS, create a new zone file named rh.ara.avast.com and create a new host record, same as parent domain, and have it resolve to the working IP address. Flush your DNS cache, check you are getting the working IP when trying to connect to the rh.ara.avast.com
-
Thanks for the suggestion. Unfortunately (or fortunately?), it appears the IP address difference doesn't matter. I forced a working computer to resolve to the "not working" IP address via the hosts file and it connected just fine. I also tried the same by adding the "working" IP address into a machine's host file that wasn't working and was met with the same error - so we're back to square one.
-
Do you use a proxy or content filter that requires authentication? Can you check the logs there to see if one of the non-working hosts is getting denied for some reason?
As a side note: I thought the remote help feature used the local server to perform its function. I could be wrong, but I don't understand why it would going out to one of avasts servers to remote help someone on the local LAN.
-
According to our content filter logs, there isn't anything being blocked. That was our first thought as well, so we took a few machines offsite and hooked them up to an open internet connection but had the same issue.
I'm purely speculating, but I think it uses the remote Avast server to generate the remote code.
-
Do your clients have an agent installed that forces them to proxy or check-in? Maybe something that would be doing SSL decryption?
Is the date and time/timezone correct on the non-working machines?
I'm grasping at this point :D
-
No to the proxy/SSL decryption question - our content filter resides inline and doesn't use any proxy settings (in other words, once you're off network, you get free reign), and yes to the time being correct on the client machines that aren't working. We're grasping at straws too! We use this feature in our helpdesk extensively for remote support and its inaccessibility is crippling us. Thank you for the suggestions thus far!
-
At this point, I would start looking for similarities between the machines that aren't working.
*Are they in the same container in AD?
*Same security group?
*Maybe based on the same version of an image file or operating system service pack level?
*Do you have WSUS or other patch management in place? Are they in the same group in that system?
*Are they in the same group in Avast! for getting their policy file?
*Did some update, patch, or configuration recently get applied to the computers in the non-working group that didn't get applied to the working group?[/li][/list]
How are they different from the ones that do work? Other than resolving to the other IP address?
At this point, I would just have to sleuth it out step by step, comparing and contrasting until I pinned it down.
-
In an attempt at further troubleshooting, we removed Avast EPS from a machine that didn't work and installed the free version. We confirmed that the remote assistance in the "free" version of Avast works without fail! The URL of the remote server is slightly different (free.ara.avast.com rather than rh.ara.avast.com), but the resolved IP address was the same in both cases. After removing the free version and re-installing the full version, remote assistance stopped working again (though the resolved IP was the same).
Needless to say we are stumped and slightly frustrated.
-
Have you checked the certificates to make sure something is not invalid or revoked on the machines that are not working? I'm grasping at straws again.
-
Can you expound a bit on how we can do this? Our subscription file states that we have an active subscription with 65 days remaining if this is what you mean.
-
Backing up a bit, since certificates are complex. Did you make sure the date, time, and time zone settings on the machines are correct? Still having to do with certificates, but not diving into the deep end yet.
-
Yes, time on all machines are synced to a local NTP server which reflects our correct time/time zone/etc.
-
I found this thread after some Googling: https://forum.avast.com/index.php?topic=133412.msg982445
It's an older thread, but someone has replied recently with the same problem we're having.
-
Any chance the problem clients have some kind of firewall or filter turn on locally? Windows firewall or maybe even Avast! shield that the working clients do not have?
-
By default, Windows Firewall is turned off on our machines and I verified that it is off on the machines we're using. I disabled all of the Avast shields while testing to no avail. I've confirmed that the issue is happening on both our Windows 7 and XP machines.
-
Have you tried uninstalling and reinstalling the Avast! client? I know it may not be a final solution, but it might help determine the underlying problem.
-
Yep, we did. Uninstalling and reinstalling the EPS client resulted in the same error. It was only when we uninstalled the EPS client and installed the free version did we get it to work. Sadly, after uninstalling the free client and installing EPS again, we're back to the error.
Interestingly, some of our machines that were working a week ago are now starting to throw the same error. It's rare that we find a machine in our environment that is working now.
-
Have you look at the log file for remote assistance to see if it may shed some light?
C:\ProgramData\AVAST Software\Avast\log\aralog.log
I'm not sure if Avast! logs to the event logs of the system, so check their also. Maybe another even being thrown around the time you try and fail to remote assistance.
-
You might be on to something here. Here's the output of that log file right when I tried a remote assistance session. It seems your thoughts on the certificate might be on point. Now - what to do to fix? ;D
2015-03-02 10:43:19,553: [ARA_DLL] INFO - Wks: WKSServer ARAWksBase::ThreadProcedure - entry point
2015-03-02 10:43:19,678: [ARA_DLL] ERROR - ARASSLSocket::VerifyPeerCertificate - Verification of the peer certificate failed,
2015-03-02 10:43:19,678: [ARA_DLL] ERROR - Wks: WKSServer - ARAWksBase::DoError - Local error 0x1000e occurs
2015-03-02 10:43:19,678: [ARA_DLL] INFO - Wks: WKSServer - The session has been teminated
2015-03-02 10:43:19,678: [ARA_DLL] INFO - External Abort of Current Session is requested
2015-03-02 10:43:19,678: [ARA_DLL] WARN - StopStandaloneServer: Server is already stopped
2015-03-02 10:43:19,679: [ARA_DLL] INFO - External Abort of Current Session is requested
2015-03-02 10:43:19,679: [ARA_DLL] WARN - StopStandaloneServer: Server is already stopped
-
You might check your non-working machines to see if they have this update installed KB3004394
http://arstechnica.com/information-technology/2014/12/microsoft-withdraws-bad-windows-7-update-that-broke-future-windows-7-updates/
-
I did have that update installed on a broken machine. I removed the update and rebooted, but the issue remains. The log shows the same error.
-
Did you: https://support.microsoft.com/kb/3024777
-
Yep, I removed the "bad" update and ran the KB fix you linked to no avail. If this was an issue with Windows Updates fouling up certificates, I would think the Free version of Avast would have the same issue (which it does not).
Additionally, that Windows Update only applied to Windows 7 and above - our Windows XP machines are exhibiting the same issue.
-
It would depend on the certificate each one uses. If you open MMC, Go to File-> Add Snap-In, Select Certificates, then do Machine Account, This machine, you can see all the certificates the machine trusts. You can also go through the same produce, but choose service account, and select the avast related stuff, and check those certificates. I'm no expert on certificates, but I can usually muddle my way through. On my systems, I can't seem to find much that is helpful.
-
I want to say thanks for all of your help thus far. We'd certainly be in worse shape if you haven't been here to lend a hand. Unfortunately, I looked through the certificates on a test machine but have no idea what I'm looking for or where to begin troubleshooting as the error in the log is a bit ambiguous.
As a further troubleshooting step, we recreated a client installer from our AEA server and uninstalled/reinstalled the client using this updated installer in the hopes that that would fix the issue but it has not. All in all, I'd say the problem exists on about 80% of the machines we have spot checked, and the number seems to be growing every day - we're becoming hard pressed to find a machine that is still working.
I had hoped to get this problem resolved without having to pay $2/seat enterprise support as it seems like it should be a simple fix, but I'm afraid we might not have any other choice.
-
FYI to all experiencing this problem - I emailed the EDU Support folks at Avast yesterday inquiring about support options for this issue. Their response is below:
This issue is due to a bug and requires a program fix or update in which case our developers are discussing methods as this issue has been intermittent and it's my understanding this feature may not be possible to fix due to the current program and requires a new update.
WE do hope to have this fixed soon but it will be some time.
I do apologize for the inconvenience and will discuss it with our developers soon.
Hopefully they'll come out with a program update soon! ;D