Is the ERA HTTP Server Broken?

[Damon85]

I couldn't seem to find a topic directly related to this, but having deployed v3 in our office here, the clients seem to work fine in most cases (no slow downs, etc.), but they will not update reliably.

I have configured the ERA server to be a mirror as well for the clients. However, after a set period of time, the clients start barking "Download interrupted." errors. Deciding to investigate further, I changed from default the option in ERA named "Disconnect from server after update." This seemed to improve the situation, but I am still seeing the intermittent errors -- I dug deeper.

By monitoring the packets coming into and out of a client and the server at the same time, I noticed an oddity that I don't think should be: The server responded to an HTTP request that was from much earlier (going by port number chosen by the client OS). If this connection has been closed by the client, the server should not be responding to it. The behavior I have noticed from monitoring the connections is that the clients make an HTTP request of the server and it keeps them waiting, failing to respond in a timely manner. The client seems to tear the connection down after the timeout period, but the server does not complete the teardown correctly, keeping the connections in the CLOSE_WAIT state. What's worse is that it actually responds after the connection has been terminated.

Is this a known bug in the software? I sent in a support case over a week ago and received no more than an acknowledgment from ESET.

[EnGenie]

Make sure that the installation of NOD32 Business Edition on the same computer as ERAS is not also configured to be a mirror server.

If so, then the NOD32 BE mirror and the ERAS mirror will fight over the same TCP/IP port (2221 by default).

Either ERAS should be the mirror OR NOD32 BE.

[Damon85]

NOD32 BE has the option to provide an update mirror disabled. Still experiencing the same issues very frequent "Download Interrupted" errors on the clients. Clients do seem to update over extended periods of time, but during the week this seems to take longer than the period between updates some days.

[circumpunct]

Sounds like port contention.

Try using 8088 for http transfer of signatures.

[Damon85]

I took your suggestion and changed the port to 8088 for the mirror in ERA server, pushed the configuration change to the clients and tried connecting with the client on my machine for an update. The update succeeded (and quickly). I then went to the console and forced all clients to update. I then tried to update with my client again, and got the usual response from NOD32 -- the file update.ver gets to 100% and then the update agent sits there, waiting for a the server to close connection so that it can complete. It does not, and the client reverts to the same "Download interrupted." error. This still indicates the same problem -- the ERA HTTP server seems to stop handling connections correctly over time seemingly by the amount of connections and most especially if they all come at once.

[Marcos]

How many clients update from the mirror via http? This method is not suitable for networks with more than 100-200 workstations.

[Damon85]

We should be relatively safe then... only 38 at the moment.

[ASpace]

I personally have had plenty different problems on clients' computers with the BE and the v3 mirror and we decided we should dump it temporary (I mean I advise corporate clients who purcahse BE to use 2.7 until its support is ended)

Try to use NOD32 2.7 and RA v1 in your network , may be you will not have such problems (I personally never had any serious problem with it) . Hope you too :thumb:

[Damon85]

Rolling back to BE 2.7/RA v1 is certainly an option worth consideration, but it doesn't really address these problems with BE 3/RA v2 and they have to be addressed before they can be resolved. It's fine with me if I have to restart the service and force definition updates via RA for a while a few times a day if it means we can correct and improve the software -- it'd just go a lot smoother if ESET would respond to support requests or even admit there's a problem, etc.

[Marcos]

If you create a mirror using ESS/EAV, does it work reliably and the problem is only with ERA?

[Damon85]

No, it doesn't work any differently with EAV running the mirror. Same behavior in fact -- fine for an arbitrary amount of connections, then the rest of them connect and then fail to ever disconnect correctly. The server doesn't seem to handle them correctly -- it's extremely slow to respond to clients, and responds after they time out (and close the connection). The server doesn't acknowledge closing the connection, and instead gets mired in trying to re-transmit packets for previously closed connections. This can be captured both on the server and at the clients. When I say arbitrary, I mean it as well. Sometimes only five clients can update before it stops working, while yesterday, all of our clients updated within 1-2 minutes and it stopped working after that. Both ERA and EAV seem to have no problem accepting new connections after the problems arise, but they will not respond until all previous connections are answered, regardless of the fact the TCP connections have already been closed (or at least an attempt was made to close them).

I don't know if this problem is an issue with EAV Mirror/ERA mirror or an issue with Windows itself, but logic would follow that if it's a problem Windows, the other features of ERA running on the same server would have similar if not the exact same issues, and that simply isn't the case. Of all the services running on the server (and it's under barely any usage), EAV Mirror and ERA mirror seems to be the only one having an issue.

I've also tried setting EAV's protection to disabled, and I've checked the system logs and the firewall log -- nothing seems to be amiss.

[Marcos]

Could you try editing the default update task and set groups of computers that will update at different times during the day to see if it makes a difference? I gather that updating via Windows shares works like a charm, the only problem is with updating via http. It's weird as no one else has ever reported this problem and we have large clients who update from mirror via http fine.

[Damon85]

I could try doing that but I don't believe I'll see any resolution overall. If we leave the clients to update at their normal intervals of 60 minutes, most of them do update -- eventually. That's to say, they manage to update after they've popped up countless "Download interrupted" errors. And then there's the fact that it's most of them, not all. It seems a few of them (never the same ones) get stuck in a perpetual state of inability to ever get a successful connection to the server. It's always around 10 of them that never seem to update when the system is left to its own devices over a few days.

As to configuring the clients in groups to update at different times of the day, I don't see how that helps us. Even if it does avoid the errors, our clients still aren't getting timely definition updates (which is already the primary problem). Is it possible that this issue is something very specific to our hardware and configuration? Sure -- I understand that, it's why I'm trying to work with you to resolve the problem. If there's some type of debugging software you need me to run, or a log to enable, I will be happy to do so and send any results to you.

I just don't buy into working around the problem, I'd rather get it fixed.

[Manu7204]

We have exactly the same problem, but more annoying since we have at the moment about 120 clients (out of 350 purchased licenses) and the ERA HTTP SERVER is crashing about 3-5 times per workday.
Usually the first thing I do when I arrive at the office is to restart the ERA_HTTP_SERVER service instead of taking care of the first coffee ritual.

I'm even thinking to make a batch file with the 2 following commands ("net stop ERA_HTTP_SERVER" and "net start ERA_HTTP_SERVER") and schedule it to run every 2 hours, but tbh it feels like a very cheap workaround.


PS. I noticed in the era_http_server.xml file an option looking like that:
<OPTION OPTNAME="ThreadNumber" VALUE="10" />

I wonder what's happening if that value gets modified 'by mistake' to 100

[Damon85]

I sent a packet capture of the TCP connection issues to ESET. I received a response to my ticket open with them on Sunday indicating that it's a bug in the software. They claim to be waiting on a response from the developers.

I had never noticed the thread limit, but it would suggest that it is indeed a problem with the threads not closing the connections correctly. If the system is left on its own for extended periods of time, the clients begin to connect at pseudo-random intervals, allowing the limited amount of threads (presumably 10) to time out naturally. If I haven't heard from ESET I may change the setting on our server.

I think the big question is whether this affects every installation of ERA/EAV mirror or if it's specific to certain platforms? We have it running on a 2003 R2 Standard 64-bit server.

[Manu7204]

Our ERA Server is on a 2003 x86 Standard R2 SP2 server.
The server is an Intel SR1500AL, a dual core Xeon and 1GB RAM, SATA Drives

[Manu7204]

Eventually I gave up and reconfigured all clients to get updates from a network share instead of http.

[techie007]

Did anyone figure this out? I recently had to setup a mirror as certain systems have no real "web" access, so they HTTP to our server via HOST entries to get updates.

We have 40-ish clients and since I set it up yesterday I've got several clients with the "Downlaod Interrupted" warning comming and going.

[techie007]

I spoke with Eset supporting the phone, and they got me to sent them event logs from the server and a couple of the clients.

The amount of failing clients continued to grow as time went by on the phone (a hour or so total, they DID answer the phone after two rings. :) ).

I rebooted and things have stayed clean for a couple hours now. We'll see how long that lasts.

I'm thinking I'm going to see if I can rig up IIS to be the server, that might be the best bet if I can do it with at least Basic authentication.

[techie007]

Ok So a new update was downloaded by the server, and clients started trying to get it. I started getting the "Download Interrupted" alerts again, as well as a couple "blank" alerts.

Here's the latest email I sent Eset:

-{ Quote: "Here’s the Event log from one of the failing clients:

2/27/2008 11:18:17 PM Update Download interrupted. NT AUTHORITY\SYSTEM
2/27/2008 10:44:04 PM Update Download interrupted. NT AUTHORITY\SYSTEM
2/27/2008 12:30:22 PM Kernel Statistical information was sent to ESET.
2/27/2008 12:20:19 PM Kernel Virus signature database successfully updated to version 2906 (20080227).
2/27/2008 12:20:11 PM Kernel Statistical information was sent to ESET.
2/27/2008 11:44:04 AM Update Download interrupted. NT AUTHORITY\SYSTEM
2/27/2008 8:49:45 AM Kernel Statistical information was sent to ESET.
2/27/2008 8:41:22 AM Kernel Virus signature database successfully updated to version 2905 (20080227).


The most recent one was ran by me manually, the just hung forever trying to get the ‘update.ver’ file and then eventually reported “Download Interrupted”

There’s nothing reported in the RA Server’s Windows Event logs.

I have 4 ESET services running on this server:

Eset HTTP Server – Set to “Manual” and it’s not running.
Eset RA HTTP Server – Set to “Manual” and it’s always running when I’ve looked.
Eset Remote Administrator Server – Set to “Automatic” and it’s running.
Eset Service – Set to “Automatic” and it’s running.

If I restart the “ESet RA HTTP Server”, and then manually start an update from the above client, it connects and updates. When I restart the service the Windows Event logs show that I stopped it and that it restarted successfully.

After a few minutes, clients are getting their updates successfully, we’ll see how long it lasts. :)

The Server is a Dual Xeon Dual-core, with 2GB of RAM running Windows 2003 R2 Standard (SP2). It’s role is DNS and ESET, and that’s it, no IIS, no other web servers.

If the “Eset RA HTTP Server” is the update Mirror, then what’s the “Eset HTTP Server” for?
" }-

Anyone been this far into it with support? Is there any steps they got you to do that I can try before they ask? :)

Anyone know the difference between the “Eset RA HTTP Server” and the “Eset HTTP Server” services?

[mayt]

Hello,

ESET NOD32 Antivirus 3.0 Business edition has the same ability of creating & providing mirror for updates as ERA does. The service "ESET HTTP Server" belongs to ENA BE and shouldn't be running when ESET RA HTTP Server is on.

[Damon85]

I haven't heard anything other than it being an issue they're aware of -- that was several weeks ago and I've yet to see any resolution. Rebooting the server takes care of the issue briefly because it restarts the service. Also, the occasional restart of the service (every fourth or fifth try, approximately) will yield a running service which is somewhat more reliable.

As I've sent to ESET via packet captures, it seems that the HTTP server embedded in ERA is not handling the TCP connections correctly, which leads to the 'Download Interrupted' chaos.

[techie007]

-{ Quote: "Hello,

ESET NOD32 Antivirus 3.0 Business edition has the same ability of creating & providing mirror for updates as ERA does. The service "ESET HTTP Server" belongs to ENA BE and shouldn't be running when ESET RA HTTP Server is on." }-

Ahhh, OK, well it's not "running", it's just there in "Manual" mode. I do see this service on the clients as well, so that explains that. Not sure why the service is installed when there's no mirror, but hey.

There are no other Mirrors set up other than the one setup in the RAS itself.

[techie007]

-{ Quote: "I haven't heard anything other than it being an issue they're aware of -- that was several weeks ago and I've yet to see any resolution." }-

Well I just called them up again to check a status on my case, and they're going to review the new info I've sent very shorty and are supposed to contact me in a couple hours, so we'll see what's what.

Perhaps you should do the same to prod them on a bit, if we keep on them apparently things get looked at faster, so if there's multiple of us calling daily, then perhaps they'll figure it out faster. I find waiting for them to get back to you can cause it to be weeks to hear back, whereas so far calling seems to keep things moving.

I find that one restart of the service is enough to get it up and running, at least until the next update becomes available, which is annoying, cause I'm not up at 3AM and such. :)

I guess I'll have to start testing that IIS idea later tonight and see if I can pull it off if they don't have an answer.

This seems like a pretty major flaw for business users and it SHOULD be fixed quickly.

[techie007]

Ok so I got an email message asking that I send them a Belarc report, so I do.

I then got an email asking me to compare my settings to Page 13 of the manual. I do, and surprise it's the exact same page I read when I started setting the thing up. :)

Here's what I sent them this time, we'll see what happens next:

-{ Quote: "I used page 13 to figure out how it worked, so it has matched that.

I’ve also tried another port, None, Basic and NTLM authentication all make no difference, it’s fine for a while, but then clients start requesting updates and eventually they start getting either a “Download Interrupted” error or a BLANK error.

It does work, it just doesn’t work when lots of clients start hitting it to get updates.

I’ve seen clients fail once or twice, and then get it’s updates the next try, while others are continuing to fail, etc. But eventually they’ll all fail continually.

Restarting the Eset RA HTTP Service (or a server reboot) fixes it for a while.

To tide me over I set up IIS on that server, pointed it at the NOD32 Update folder that the RA fills, and turned on basic authentication.

After confirming it worked from one client, I turned off the Eset RAS internal HTTP server option, and switched the IIS port over to the custom port I’m using for the client updates.

Within minutes the clients started getting their updates properly, and a ton of updates went out, including Component Updates, and there wasn’t a single error. It’s been running almost a full day now and there hasn’t been a single update error from any of the clients.

There’s something BROKEN about the RA Server’s HTTP mirror server, and I’m not the only one seeing this problem. My fear is that the same flaw is also in each of the Clients, which could cause the same problem if I turn one of them into a mirror server for another building.

What next?
" }-

Ever since I replaced the internal Eset HTTP server with IIS6 I havn't had a single update error, which isn't too surprising.

If anyone wants to know how to setup IIS6/2003 to be the mirror, let me know and I'll post some info, there was a couple minor snags (ie: MIME), but nothing too bad.

I'd still rather use the internal HTTP since I'm kind of 'forced' to have it installed with the RA anyway.

[techie007]

Well IIS didn't have a single problem all this time, but I finally got another responce from Eset:

-{ Quote: "Can you try to set the "Disconnect from server after update" option on the clients to enabled?

It's in the configuration editor under Update -> Profile -> Setup -> LAN.

That may resolve the issue of http requests persisting past their lifespan, and may reduce the "clobbering" of the http service.
" }-

But today I also see that there is an update for the RA server and colsole (2.0.50). One of the fixes listed is:

"Fixed several problems related to
http server"

See http://www.eset.com/joomla/index.php?option=com_content&task=view&id=1243&Itemid=5

So I turned IIS off, and turned the internal HTTP back on (after updating the RAS and console), and we'll see how it goes without doing the above option.

[techie007]

Well the internal HHTP server survived one round of updates and then puked again overnight, same errors. Download Interrupted and "blank".

Turned IIS back on and it's good to go. Later tonight I'll attempt the internal HTTP with the Option they suggest above and pray. :)

[Damon85]

Everything seems to be working here so far (approximately 24 hours). I had the 'disconnect after update' setting already enabled from before, so I simply left it enabled.

[mzdaspd3]

-{ Quote: "How many clients update from the mirror via http? This method is not suitable for networks with more than 100-200 workstations." }-

This information is not in the documentation, and was not disclosed to me by the pre-sales engineer who assisted with our evaluation of this product who told me there would be no issues with having 1500+ clients obtain updates using this method. Why do I have to visit a forum to learn about a significant limitation of what is being pushed by your support staff as the 'preferred' configuration.

To add to this, I've got clients showing up multiple time in the console that have to be manually deleted, because (according to your support) the RA server can only track client by IP address.

The further I get into the implementation of this thing, the more I realize this is NOT an enterprise ready product.

-{ Quote: "If anyone wants to know how to setup IIS6/2003 to be the mirror, let me know and I'll post some info, there was a couple minor snags (ie: MIME), but nothing too bad." }-

Would you mind posting the steps to get this set up using IIS? I would be most appreciative.

[techie007]

Sorry to not get back to this sooner, but I'm still on it. :)

Eset asked me to turn on that option, and then they also talked about me using UNC paths instead. Here's the latest letter I just sent them, it explains where I'm at right now.

-{ Quote: "Hello,

Other priorities have prevented me from switching back from IIS to the internal HTTP.

Using UNC paths is out of the question for us as we have clients on multiple networks, so we have to use HTTP.

The option you have asked me to set seems to be LAN-only related, but I have it anyway, and as well, set the same option (“disconnect from server after update”) under the “Mirror” configuration in the Eset Configuration Editor.

I have now turned IIS off and turned the internal HTTP back on. I tested with my local client and the connection is good.

I set the above options and pushed out the config., currently the clients are up-to-date, and it usually takes two rounds of updates before the problem shows, so I should have more info later tonight, or tomorrow, depending on how fast new updates are released.
" }-

If things go as they have been, I should have many failures come tomorrow morning.

[techie007]

-{ Quote: "Would you mind posting the steps to get this set up using IIS? I would be most appreciative." }-

-{ Quote: "Would you mind posting the steps to get this set up using IIS? I would be most appreciative." }-

NOTE - Assumes IIS6/Windows 2003 and some know-how on how to use it. :)

In the RA console, go to the Server Options and then the Updates TAB.

Setup your Server Updates password and such.

Checkmark "Create update mirror", and pick a folder to store the updates.

Uncheck the "Provide updates via internal HTTP".

Hit the update button, and make sure that the Folder fills up with updates (may take a couple minutes).

Create a user in Windows (i.e.: NODUpdtUser), either local to the machine, or domain based, and pick a password, which you set to not expire.

Ensure this user has Read rights to the Nod32 Update Folder.

If IIS isn't installed: Install IIS in its minimalist form, and delete the default site via IIS Manager.

In IIS manager create a new website, and point its "Home Directory" at the folder you created via NOD32 that holds the updates.

Since IIS6 limits which file-types are allowed to be streamed out of the server, you must adjust the Mime settings for IIS to allow the file types in question. Since I'm only using this IIS install for the NOD updates, I chose the much easier way and just allowed ALL MIME file-types. This can be dangerous if you have other web sites running, as it's a server-wide setting.

To allow ALL MIME types to be downloaded go into IIS Manager and right-click the Server name (not the website), and pick properties.

Click the "MIME Types" button.

Click "New".

Set the Extension to "*" and the MIME Type to "application/octet-stream".

Hit OK, OK, Apply type of thing until you're back at IIS Manager.

Edit the properties of the NOD32Update website you just made, and change a couple things:

Under "Website" Tab: TCP Port - Set it to a custom one for better security (i.e: 1234)

Under "Documents" Tab: Uncheck "Enable Default content page".

Under "Directory Security" Tab Click "Edit":

Uncheck "Enable Anonymous Access".

Checkmark "Integrated Windows Authentication"

Checkmark "Basic authentication"

OK, OK, Apply, until you're out of IIS.

You should now be able to Open IE and surf to your site on your port.

The default Document is off, so it won't display anything, unless you specify a file, so surf to: "http://your.server.com:1234/update.ver".

Enter the name and password you set up, you may have to specify the domain or computer name (i.e.: User name: "myDomain\NODUpdtUser").

And you should get a screen full of text (the contents of Update.ver - i.e.: "[EPFW0] platform=x86 versionid=1031 type=epfw group=epfw,ra date=...")

That means it’s working. :)

In the ESET Config setup the clients, which should be that exact same as if you were using the internal HTTP with NTLM turned on:

Update Module -> Profile -> Setup:
- Update server: http://your.server.com:1234 (don’t forget the “HTTP://”!)
- Username: "myDomain\NODUpdtUser"
- Password: <password you picked>

You can set the rest up however you’d like.

TADA it should now work.

With this setup I can switch back and forth between IIS and the internal by simply enabling one and disabling the other at the server.

Extra info: “Basic Authentication” kind of sucks, but with a custom port it should be fine, unless you really think someone is sniffing your NOD32 update server to try and get free updates.

NTLM is available in Windows server as part of "Integrated Windows Authentication", and since the NOD32 clients can use NTLM, it would be a better choice and you wouldn’t need “Basic Authentication” set in IIS, but this wouldn’t work for me…

From what I’ve gleaned off the Internet if the II6 server is in stand-alone mode NTLM will work, but if your IIS6 is on an AD domain (as is mine) they prefer Kerberos over NTLM, which the NOD32 clients can’t do, and apparently fail, so "Basic Authentication" is needed. I read that one could set the server up to use NTLM by disabling Kerberos with the following command:

c:\inetpub\adminscripts\> cscript adsutil.vbs set w3svc/NTAuthenticationProviders “NTLM”

I haven’t tested it, as my ultimate goal is to use the Internal NOD HTTP server and remove IIS completely, and I’m not too worried about it being sniffed before then. :)

Wheew, long post, hope this helps. :)

[mzdaspd3]

@techie007 - Thank You!

[techie007]

Less than 24 hours later the errors are back in full force.

Here's what I sent Eset at about 12:30 today, no word back yet.

-{ Quote: "Ok The Internal HTTP server has been running since I wrote that message (about 21 hours) and now that there’s been an update and the clients are checking in, they are failing again, with the same issues as before -- “Download Interrupted” no ‘blank’ errors this time so far...

I’m turning IIS back on until you have some other ideas." }-

I also pushed the config to turn off those "disconnect from server" options.

And upon futher inspection, there WERE some "Blank" errors.

We'll see if they finally figure out if/how it's broken.

[techie007]

Heard from support again today about this case, and they suggested I try the .56 version of the server that was just released, as it apparently has 'several HTTP server fixes' in it.

I turned it on at about 3:30PM so we'll see if it fails by morning.

So far so good, but that's probably only because there haven't been any new updates to give out since then. :)

[Damon85]

I have not been experiencing the problems that you have with 2.0.50 or 2.0.56 (I upgraded shortly after that was released). I think the difference could be that I changed the "disconnect" setting in the ERA configuration (check server options and go to the advanced options with the configuration tree) and on the clients as well. It could be that it needs to be set in both places.

[techie007]

Well it's good to know it started working for you, it gives me hope.

The disconnect settings confuse me - the one in the ERA Server/Update branch is for when the RAS connects to the master server (ESET) to get the updates to put in the local cache for the clients.

The one listed under the Update Module/Profile/Setup/Mirror branch is for when a client configured as a mirror checks into the RAS to get updates to mirror out.

The one listed under the Update Module/Profile/Setup/LAN branch of for when you're connecting to a LAN folder.

If this isn't right, then they need to clarify that in the editor, but I'm pretty confident it's not the problem anyway since the clients have no trouble connecting or disconnecting from IIS with all those set to "No", and when I did set them to yes (minus the one in the ERA Server/Update branch) it made absolutely no difference.

Here's what I sent Eset support just a few minutes ago:

-{ Quote: "So it lasted from 4:30PM until about 6AM, and then my local NOD32 client started failing to connect. So I restarted the ESET RA HTTP Server service, and I could then connect again. That lasted until about 11AM-ish when many of the clients started calling in to get an update and failing, same as always.

Any more ideas?" }-

IIS is back on again. :)

[Damon85]

I agree -- if what I posted is indeed the case with the disconnect settings, then it is certainly confusing bordering on nonsense. I think that case could be made regarding the necessity of such an option anyway, though -- why do we need an option to have clients disconnect after they're finished updating or what's the purpose in keeping them connected in the first place?

Had you ever done a packet capture, especially recently, to see if you were experiencing the same behavior I was able to capture? It's possible that you have more clients than I do and ESET merely increased some threshold.

[techie007]

OK here's something weird.

They requested I set up one of the clients on another computer as an HTTP mirror and aim the clients at it to see how it acts.

I managed to get the mirror up and running and updating, but when I try to connect my clients to it with any authentication (aside from "none" setting) my test clients can't connect. They don't get "unauthorized" they get "Download Interrupted", immediately. If authentication is off, it works.

The strange part was that before I actually had any update files replicated on the mirror (or if I manually delete them) the clients could connect, with NTLM or Basic, and would get "File Not Found On Server", which is what I would expect.

The Mirror is another dual Xeon server, one test client is on the same LAN, and the other is via the Internet.

I haven't done any packet capturing, and I don't really want to, they can arrange to log one of their techs in and watch it for a while if the want, but we (support and myself) haven't gotten that far yet. :)

[techie007]

Well I guess I made a mistake when I asked an additional question about authentication in my last email to them.

I asked if it was nessicary to speicify a domain name in the user name when using their NTLM authentication for the HTTP server.

Thi sapparently confused them and instead of continuing on trouble shooting my problem, or an answer to my extra question, all I got was a long email explaining how to set up UNC paths! WTH?

Here's the perhaps not-so-friendly reply I sent, still waiting to hear back:

-{ Quote: "OK we’re getting WAY OFF TRACK.

Let’s start over.

I don’t want (can’t) use UNC paths. I have been a professional computer tech for more than 10 years now. I know how to make UNC paths work, and how file-system security works.

Please keep this in mind when responding so we can advance toward getting your software working as expected.

I set up the test HTTP mirror like I was asked, even though I don’t see how it was supposed to help my RAS HTTP server from crashing after less than 12 hours. Setting that Mirror up introduced ANOTHER, separate problem, that may or may not be related.

So instead of addressing the new Mirror authentication weirdness I pointed out, or continuing to work on the original problem with the RAS HTTP server, or answering my question in regard to username format for NTLM HTTP connections, you just give me a bunch of unrelated information about UNC paths. And this isn’t the first time since I opened this case that I’ve been told how I can use UNC paths.

Seriously., this is dragging on WAY to long.

Lets go over the problem ONE MORE TIME.

I want to use the HTTP server inside the RAS server with authentication turned on.
I set it up and it works, for about 12 hours, at which point it stops accepting connections.
If I restart the service it works for about another 8-12 hours and then stops accepting connections again.
Whenever I use IIS on the same machine INSTEAD, it works without incident.
The HTTP server component obviously has a problem, it’s NOT a configuration problem, it’s NOT a hardware problem.

I don’t even CARE that the mirror I was asked to set up as a test on another computer doesn’t work at all with anything other than NO authentication – at least I don’t care right now, as I’m just trying to get my RAS Server’s HTTP server up and working, so I don’t need IIS installed on the system.

SO – what’s the next step in getting the HTTP internal server on my Eset RAS working for more than 12 hours at a time?
" }-

[techie007]

OK So, to continue this fun story.

The next thing they asked me to do was enable a bunch of exclusions for Exchange, which I'm not running on any of the servers or clients.

And they also requested I disable 'email protection', 'web access protection', and 'http checking'.

And then my favourite part: "since you are running ESET Smart Security on the server, click on Personal Firewall and set..."

I'm not running ESS, I'm using NOD32 Business, you think they'd know that by now.

Anyhow, I wasn't sure if they intended for me to perform these actions on JUST my RAS server, or ALL the clients. So I responded and asked for clarification:

-{ Quote: "So I should be applying these settings to the client on the server that’s hosting the RAS HTTP Server only? Or on ALL the clients who are trying to connect to its HTTP server for updates??

Can you please explain to me how disabling most of the protection on my client(s) is expected to help the HTTP server answer requests properly for more than 12 hours? I’m not sure I follow the reasoning as to why I’m doing this, and if I don’t know why, and it doesn’t make sense to me, I’m not sure I want to commit my time to testing what seem to be totally unrelated configurations. Know what I mean? I answer to someone who pays me for my time." }-

To which I got a response of "In the advanced setup go to Update, click on advanced update setup, go to the LAN tab and check "Disconnect from server after update"."

!!!!

Gee thanks guys, any more things you just want me to try over and over for no reason?

How about ANSWERING MY QUESTIONS?

Anyhow I'm simply going to respond and say I already did it, and suggest they look here to refresh their memory.

I know it's April 1st today, but common, this shouldn't be such a joke. :)

[Damon85]

I wouldn't feel bad about it -- I had to have a similar exchange with them when I started getting back responses I knew wouldn't accomplish anything or completely addressed the wrong issue. It seems like the Tier 1 workout -- jump you through meaningless hoops while they try to actually isolate a problem. While I would certainly keep crawling up their backside to get things fixed in an efficient manner, I'd rather be told that they're still investigating it than misinformation and useless workarounds. Giving me useless work to do won't get me off their back, nor will it improve my disposition.

[alexsch8]

I was using the HTTP mirror with RAS 2.0.33 with no issues ever. Last night I upgraded to 2.0.56 and now all my clients are saying "File does not exist", as if the HTTP server component isn't serving the files. But the machines update fine via UNC.

The server is running RAS and EAV, mirroring is turned off in EAV and RAS is used to serve the updates. I have checked my config settings over and over but it just isn't resolving. No config changes were made from the previous, working setup on the clients or server except new program components in the 2.0.56 update.

Judging by the responses here this issue is not yet resovled. I will try the IIS method - thank you techie007 for that.

[alexsch8]

So, after having spent quite a bit of time last night trying to get the RAS HTTP server to serve updates without luck. I got back to it this morning only to find that it works fine now. Go figure... using RAS 2.0.56...

[techie007]

Well as it stands right now, Eset called me (out of the blue) and Jeff (eset support) went through the settings he wanted me to set (like turning off Web and Email scanning, turn off "Scan all files" etc.) and not surprisingly it didn't help in the least, one round of updates goes OK and then the HTTP server craps out until it's reset (restart the service).

I haven't had any more time to spend on this, so I've just been using IIS still.

I'm starting to wonder if the HTTP server's files didn't get updated properly when I went to 2.0.56. Again I just haven't had much time to investigate this recently.

My next trick is going to be to install RAS 2.0.56 on another server and then just take all the files and copy them over-top of my production RAS to ensure they are all at the latest versions.

Perhaps by the end of the week/early next week.