Is the ERA HTTP Server Broken?

Discussion in 'Other ESET Home Products' started by Damon85, Dec 11, 2007.

Thread Status:
Not open for further replies.
  1. techie007
    Offline

    techie007 Registered Member

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

    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.
  2. techie007
    Offline

    techie007 Registered Member

    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. :)
  3. Damon85
    Offline

    Damon85 Registered Member

    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.
  4. mzdaspd3
    Offline

    mzdaspd3 Registered Member

    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.

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

    techie007 Registered Member

    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.

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

    techie007 Registered Member

    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. :)
  7. mzdaspd3
    Offline

    mzdaspd3 Registered Member

    @techie007 - Thank You!
  8. techie007
    Offline

    techie007 Registered Member

    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.

    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.
  9. techie007
    Offline

    techie007 Registered Member

    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. :)
  10. Damon85
    Offline

    Damon85 Registered Member

    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.
  11. techie007
    Offline

    techie007 Registered Member

    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:

    IIS is back on again. :)
  12. Damon85
    Offline

    Damon85 Registered Member

    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.
  13. techie007
    Offline

    techie007 Registered Member

    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. :)
  14. techie007
    Offline

    techie007 Registered Member

    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:

  15. techie007
    Offline

    techie007 Registered Member

    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:

    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. :)
  16. Damon85
    Offline

    Damon85 Registered Member

    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.
  17. alexsch8
    Offline

    alexsch8 Registered Member

    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.
  18. alexsch8
    Offline

    alexsch8 Registered Member

    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...
  19. techie007
    Offline

    techie007 Registered Member

    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.
Thread Status:
Not open for further replies.