Update from mirror server hangs randomly

Hi there,

I have a strange problem and haven't found a solution in the forum. Maybe you can point me in the right direction.

We use a NT 4.0 SP6a server as a mirror server and NT 4.0 Workstation and Windows 2000 on the clients. Retrieving the updates from the nod servers to the mirror server works fine.

For updating the clients I have enabled the http access method on the mirror server and configured the clients to get their updates from http://192.168.22.53:8081 as I did many times before without any problems in different offices.

But here when I manually start the update the client in this case begins to retrieve the file nod2B3A.log and after 183 KB or 6% it hangs. When I abort and restart the update it tries to get the same file and hangs again, this time after 3%. After restarting again it hangs after 74% while getting nod5EC3.nup. In the logs I only see a message saying that the update attempt failed, because the download was interrupted. I have the same problems with all NOD32 clients.

Permissions on the NOD32/Mirror directory is Full control for everyone.

Do you have any ideas?

Thanks a lot.

+rainer

 

Have you tried (for grins) just using a UNC path from your clients to the server? ie: \\server\nodmirror\whatever ?

You might try this and see if it'll do it's thing, just to rule out a bad cable/switch. Doesn't sound like a port problem, as you're at least getting *some* data...

Let us know what you find out!

 

Thank you for your help.

What I forgot to say: the NOD32 mirror server is also our primary domain controller and file server. So the network must be ok as we regularly save files on the server.

Here is what I did:

Server
* shared d:\Data\NOD32 as NOD32
* removed the tick "Enable access to files via HTTP protocol"
* left login name and password field blank

Client
* configured //hupserver2/NOD32/Mirror/ as update path
* left username and password field blank

When I then try to update I am asked for a username and password. I tried a few user accounts which are valid server accounts but none is accepted...

 

While you wait for a couple of our big gun RA users to come along, can you please send an email to support@nod32.com and place a link to this thread. If you do not hear from Eset within 3 days (allows for weekends), please advise us here...

We would appreciate if you could keep us in the loop with your progress, as we all learn this way…

Cheers

 

Email is on it's way.

In the meantime I found out that a few clients seem to update without problems.

Could it have something to do with a misconfigured comfig.xml file? I started with a config file, which I took from another installation. As I enountered the update problems I removed it and installed a few more clients. I can't confirm but it seem's that all but one of the clients which were installed after the removal from the config.xml file seem to work and the other's don't even after a complete uninstall and reinstall of NOD32.

For now I disabled the config.xml file. I think a step-by-step approach would be better. First I would like to fix the update problem, then I will enable to config.xml file again.

Is there anything I can do to give you more information?

 

Not me I'm afraid, I don't have any experience with RA, though in time I will

As I said, we have several big guns with very large networks (2500+ PC's on one of them) and they are exceedingly knowledgeable in this area...

Cheers

 

Just a couple of things:
- Updating via HTTP is not suitable for networks with more than 100 clients
- when updating via Windows shares on NT systems, you need to authenticate yourself when connecting to the server. This can be accomplished by specifying the username in the update setup as workgorup(domain)\computer_name or setting the option for connecting to update server as a currently logged user. Also, you can use a specific account for connecting to the server. For more info on updating NOD32 from local mirror, please read the manual available at http://www.nod32.com/nod32network.pdf

 

Hi Marcos, thank you for your hints. Here my comments:

This network consists of 30 clients. But until now I have installed NOD32 on only 10 PCs so that should be ok.

I would rather like to use HTTP mode but of course we could try it with a shared directory for testing. I read the NOD32 in an Network Guide but it says not much about authentication. So I have a few questions:

Mirror Server
==========
What Login Name / Password should I enter in the "Access to Update files" section? The manual says nothing about it.

What should I select in the "Connect to update server as" section. The manual isn't very clear about this. Why do I have to tell the *server* how the clients connect to the server? Isn't it enough to tell the *clients* how to connect to the server?

Client
=====
What Username/Password do I have to specify in the "Update Location" section? You said domain\computername. Is that really correct? And what password?

I tried domain\computername, but when I start the update I am asked again for a username and password.


Is there nor dcumentation that describes the update-via-shares method in detail? The Network manual seems to eplain only the HTTP method.

 

The above is how I've worked the updates with our clients, except the http protocol is left selected, and it works ok.

Does the account trying to connect have permissions to the mirror--not only at share level, but any inherited permissions that might be causing a state of fubar?

 

Yes, I checked the permissions. Full control on share and file level. I can browse, read and even write to the shared folder using the explorer.

To me it looks like a server problem. A few minutes ago I installed and configured another server as a mirror and using this one the update worked. Unfortunately we can't use this server so I have to make it work with the original mirror server.

What about a complete uninstall and reinstall of NOD32 on the server? Can I be sure that *everything* related to NOD32 is removed when I do an uninstall? Or do I have to search the registry and remove entries manually?

 

On the mirror server, there's no need to specify any username/password whatsover unless you intend to store copies of update files on another machine in the LAN.

On clients, you have several options:
1. in the main update setup panel, set the username as workgroup(domain)\machine_name. No password should be required unless you authenticate as a user with a password set.
2. in the advanced update setup, you can select to authenticate on the server as a currently logged user. Alternatively, you can specify an account with access to the server - this is usefull if no one is actually logged in.

 

Hm, it looks like I have to set out for my customer's office. Didn't get it to work via remote control. I'll be there in 30 minutes.

In the meantime, do you know an answer to this by chance: https://www.wilderssecurity.com/showthread.php?t=61198

That would make testing much easier.

 

Ok, updates via shared folders work now.

Update Main Section
================
To get the updates from the mirror server I had to tell the client machine to use a user which exists on the server. The username has to be given like this: domain_name\user_name. The user's password must also be entered.

To set the username like domain_name\machine_name and without a password didn't work which doesn't surprise me. On domain servers or any Windows servers there are by default no users with the machine names of the clients as their names and no password set in the user database. I doubt that this has ever worked... Or did I misunderstood you and you ment to create these users on the server? If so, let me reply that I don't regard it as a good idea to create users with no password set...

Update Advanced Section
====================
I left "Connect to LAN as" on "System account (default)". To be honest, I have no idea what this setting is good for. What does it mean to connect to a LAN

I have the feeling that I don't really get the point of how the authentication scheme works. There are two places to specify user names and passwords on the update mirror in the mirror section and two places on the clients in the update section. I would welcome a manual which explains in detail what these settings mean so I don't have to trial-and-error so much.

After all, update via shared folders work, but updates via http still don't. Is there anyone who can help me? Could it have something to do with Windows NT 4.0 Server as mirror server. It is the only difference I can think of...

 

I dunno about the "exceedingly knowledgeable" part, but I do have that many PCs...

First - I became rather disenchanted with the fileshare update method 'way back when I was first evaluating NOD v1.x, so I went HTTP and have never looked back.
Second - Don't let Marcos fool you - HTTP works fine for >100 users - I update 460 users at my own site from my master mirror server while feeding (via HTTP) all of my downstream servers, many of which support >100 users at their site. So I can vouch for the robustness of the HTTP update method from Eset.
Third - NT4 is not an issue. My master mirror is NT4 SP6, and it feeds both NT4 Server and 2000 Server slave mirrors at my other sites, along with 9x and Nt/2K clients at my site.
Fourth - You don't need to set any permissions on the update directory for HTTP, so that's a real consideration there.


Your XML file may indeed be the issue here. How did you use it to load your problem machines? We've had great luck using a simple batch file to do the loads, referencing the XML file in the install line:
setup.exe /silentmode /instmft /cfg=nameofyourconfigfile.xml

Works every time for us, at least. Have you tried doing a manual installation without the XML file to see if that solves the problem? If it does, then you should consider recreating the XML file from scratch. If not, you may want to consider setting up a mirror only box for testing, so that you can remove any issues that might be caused by having your mirror on your domain controller (with your Full Control share... )

HTH,
Jack

 

Hi anotherjack,

thank you for your valuable remarks. I am glad to hear that the HTTP method is the preferred one and am impatiantly awaiting the day at which I can reconfigure the clients to update via HTTP.

But before switching to HTTP mode let me be sure that everything is ok now.

Updating the 10 clients work for 5 days but I have an "Update attempt failed" event in the clients event log every nearly every hour.

Is that normal? Maybe the original problem still exists but doesn't stop the clients to update via shared folders but via HTTP.

 

You may want to set up a test environment with another NT4 mirror server that is not a DC, then set up a test machine or two to test the HTTP updating. If you don't have the resources to do that, then I'd still set up a separate mirror server with HTTP and switch a few of your problem machines over to it to see what happens. I've had no problems whatsoever with the HTTP updating, aside from a few failed updates, and they've been few and far between.

Jack

 

Ok, that's what I will do. I don't have a server which is not a DC but I will use the Backup DC as a mirror server with HTTP and switch a few machines over to it.

I'll get back to you as I have some results. Please stay tuned.

 

Did it, done it, like it.

Well, not really. I installed the same version and used the same file for the installation. I swear!

But nevertheless the user interface looks slightly different. No eye in the upper left hand corner for example. And I found a different "Version of common control components" in the NOD32 system information section. 5.81.4522 vs. 5.81.2919.

What did I wrong this time?

 

The lack of vision (no 'eye') sounds like you installed without the graphical user interface (which I don't use, either). You might want to follow the advice of a few others here and do a full uninstall of the software, re-download a fresh copy from Eset, and reload it, WITHOUT using any XML files or anything. Here's my setup process for the mirror servers:

1. Download and run the NDNTENAD.EXE file from Eset
2. If offered the Install updated MFC libraries option, click Yes
3. Select Expert Install for the installation type, then click Next
4. Accept the license agreement, then click Next
5. Accept the default installation location, then click Next
6. Select the options for Silent mode and Protect Settings with a Password, enter your desired NOD32 password, then click Next
7. UNcheck the Graphical Interface option, then click Next
8. Check the box to Send warnings via email, then click Next
9. Enter the necessary information for the email parameters: SMTP server is YourSMTPServer, sender address is Something@GoesHere, addressee is Whoever@YouWant - then click Next
10. Enter your NOD32 UserID and PW, then click Next
11. Check the box to Make NOD32 start automatically, then click Next
12. Make sure that both the options for Desktop Icon and Shell Integration are checked, then click Next
13. UNselect the IMON option, then click Next (NOTE - We don't use IMON on intranet file servers, you do what you feel is best for your instllation.)
14. Click Next to start the installation
Click Finish when completed and allow the server to reboot.

That's a pretty much verbatim install for our servers. As to the mirror setup, it's a bit longer, but here's the basic layout I use:
1. Create a C:\NOD32 directory with an XML directory under it
2. Put your XML file (or for me, the 27 ones that I use ) into it
3. Set up your mirror information to put the update files in C:\NOD32 and CREATE A NEW XML file in the C:\NOD32\XML directory using the Config Editor.
Note - When creating a file from scratch, I recommend (dunno what Eset says) that you double click EVERY OPTION in the XML editor, so that they ALL have the lil' blue dot by them. It at least used to be that if you didn't, then things might get a little screwy. It'll make the file bigger (up to around a total of 22k or so...), but it's another variable taken out of the equation.
4. Set up the machine to mirror the files via HTTP, and set the mirror file location to C:\NOD32. Don't bother setting up a share to C:\NOD32, the server takes care of feeding the files to the users.
5. Make sure that your NOD installation is set to feed that particular XML file to the users.

That pretty much covers that.

Finally, install the test client(s) normally (no XML file), making sure that you set the update location to point to your mirror. Once everything's working, you can use your new XML file and the batch file I mentioned before to install additional clients. That should do it. Let me know.

(edit) In retrospect, it looks like you got it working, but were just wondering about the component versions. Oh well, maybe this can help someone else as well...

Jack

 

Make sure in your config file that you have it set to Program Updates to automatic. I agree with AnotherJack. I have over 900 pcs and I use the http update.

 

I never have any of my mirror servers on automatic, but all of my clients are set that way. This way, I control the propagation of the PCUs on my own schedule.

 

Thank you for your detailed explanation, Jack. This is pretty much the way I did it. Except the double-click thing in the xml-file.

I now have a our BDC running as test mirror server and switched 3 clients to it. I am curious if it works.

But I don't want to wait until the next update. Is there a way to force NOD32 to update, so that I can immediatly see if it works?

Cheers.
+rainer

 

If you're offering the XML configuration file via the mirror server, all you have to do is change the ID in it with the configuration editor, then save it. Then do a manual update from the client and you should see (probably just for a split second) the XML file being downloaded. I've found that this is the easiest way to do it, short of a reinstall on the client, especially if all you want to do is see if they're talking.

Jack

 

Hi again,

since I moved all my clients to a mirror server which is not the PDC the HTTP update works without any problems. I also followed your advice and doubleclicked ever option in the config file editor.

I will copy the working xml file back to my PDC and switch a few clients back to it to see what actually caused the problem. If not, it must have something to do with the PDC function...

Stay tuned, I will keep you well informed. ;-)

Cheers.
+rainer