Back in December we received a response from Symantec, see below. They said they removed the detection but it could be that it is back again. We will check that out. Thank you for letting us know.
In relation to submission 12613.
Upon further analysis and investigation we have verified your submission and, as such, the detection(s) for the following file(s) will be removed from our products:
File name: agent.exe MD5: 6e8f173ac4686a122b2a599821f63d8d SHA256: e41f8f603ef2292f8f9b18c40ae167243f4180fa835bbf67c3d533348d2e7e32 Note: Whitelisting may take up to 24 hours to take effect via Live Update
Starting version 6.5 an Internet-ID code is unique for each PC. It is always the same. For backward compatibility, if you upgrade older Hosts to the new version their Internet ID is not changed so that you can still connect to them using the old ID. However, once you manually change the ID on those Hosts it will change to a new value and will stick to that value from then on.
BTW, let me explain what happened in the situation described by the initial post in this thread. We resolved this through the tickets and the problem was the machines were cloned after the ID was generated. The Internet ID code is stored in the Host settings in Windows registry. If you install the Host, then generate the Internet ID and then clone the machine, of course you clone everything including the Internet ID code.
So the proper way to do that is to clone the machine after you install the Host but before you generate the ID. In other words,the ID should be generated once the machine is deployed.
Remote Utilities is slow because of their own servers that translate the ID's they provide to find the other remote servers (via internet) .... its so slow to the point that it doesn't even work.
question is:::::: what is the point to this software if you cannot even connect ?
If none of our free license users and paid customers couldn't connect, then we would have apparently been flooded with complaints here on this forum and in the tickets and refund requests sent to our Sales department. No one would have paid for software that doesn't work, especially corporate customers.
They obviously have not upgraded their servers or even consider to support their users. they expect us to upgrade to a paid version for a service that doesn't even work.
Sorry, but this is not true. Our free license has no limitations in terms of server access or bandwidth. If connection is poor then it's a technical problem which must be troubleshooted and resolved, and not a licensing problem.
We are interested in making the free version work well, that's why we don't apply any limits except the 10-PC limit. Our servers are monitored in terms of their load and bandwidth , and they are far from reaching their limit even at peak hours.
I dont think Remote Utilities even cares about their users to be honest, they keep blaming the public for their problem when obviously 100% without a doubt it's their servers.
We do not blame anyone. We just look at the specifics of each case and try to investigate the problem.
Is remote utilities planning on upgrading their servers to support their current users ?
Our servers (both software and hardware) can handle 100x more connections that they do now. But they are currently focused on US and Canada, and we have plans to expand to Europe and other continents soon.
Could you please tell us where your Viewer and Host are geographically located? What program version do you use on both sides? Finally, send us the Host logs - you can find them in C:\Program Files\Remote Utilities - Host\Logs\ - this can help us see what's going on with your connection.
If you have an outdated version (i.e. earlier that 6.5.08) it is recommended that you upgrade first. Then, if the problem persists, send us the logs.
After some brainstorming here we couldn't come up with an explanation for this :) Perhaps, it's about specific settings or hardware and how they behave in this situation. Or, rather cause the Host to behave.