Install Script Package Intermittently Does Not Work

Discussion in 'Other ESET Home Products' started by TheFourthFerret, Aug 16, 2007.

Thread Status:
Not open for further replies.
  1. TheFourthFerret

    TheFourthFerret Registered Member

    Joined:
    Aug 15, 2007
    Posts:
    2
    I am trying to work out some kinks after rolling out NOD32 Enterprise on a school network. I set up the NOD32 infrastructure with 4 administration servers to support close to 800 clients (one main server on the main campus and the three others at remote buildings, which report back to the main one, but pull updates for their mirrors directly from Eset).

    I am focusing on the main server, which handles 3 buildings (each building and remote site has it's own subnet).

    I have set up config files and installation packages for each server, so the clients pull updates and are administered by their local server. Initially, I had exported installers for script installs for local machines from the local server, but recently exported all packages from the main server for simplicity (yes, all installs now pull down from the main server, but the bandwidth consumed by this isn't a problem and a central install server, and therefore point of troubleshooting, at least until the problem is solved, is handy).

    We have created images for all workstations (Norton's Ghost) so all machines with of the same generation and hardware setups have the exact same software environments, and in general, software, installed applications, etc. are the same across the board with all images. We are also running a Novell network.

    The problem:
    With some workstations, we noticed after running the script, NOD simply didn't install. After ensuring communication with the server, and running the installer directly from the network location (browsing out to the little .exe file and manually running it apart from the script) an hour glass would show for a split second and still nothing would happen. Checking logs, we found the following:
    from the "nod32installer.log" file:
    And the "nod32ra.log" file:
    Note: These entries are not from the exact same install, or lack there of, but each time we have had the problem, we'd see the "0ms" entry in the ra log.

    We haven't found any pattern in terms of which workstations are affected. Some install perfectly fine, and one right next to those with the same hardware and software image, won't pull it down.

    Also, we have found that "pushing" the install from the server, using the exact same package works every time on the problematic workstations. We have been using this as a work around, but for the long run, we need to get the script install working.

    Extra info:
    The main server is also running WSUS, but I haven't found any conflicts between that and NOD32. Could this be it? Wouldn't all installs fail if there was a conflict?
    Command switches for the install packages are as follows:
    I have not run into any errors or found any conflicts with port 2224 on the server either.

    Any ideas?

    Thanks in advance!
     
  2. murdamcloud

    murdamcloud Registered Member

    Joined:
    Jul 30, 2007
    Posts:
    19
    Hi mate-I have had similar issues with my scripted install. however, now I cannot push install to certain machines either-identical machines seem to be fine.

    I have checked most of these suggestions below for trblshooting so far and am working on it now:

    "
    Can you ping the client <-> server both ways?
    Have the WinXP workstations disabled Simple File Sharing? (From any Windows folder window, Tools->Folder Options->View tab->bottom of list)
    Have the workstations got firewalls running that are blocking the remote configuration? (only needs to be disabled during installation period)
    Can you remotely log on to the client(s)?
    Can you make sure you have a correct administrator Username and Password set in the RA Console remote installation setup?
    From one of the workstations, can you run the Command Prompt: net use \\servername\ipc$ (to establish IPC connection to the server - make sure the 'spaces' are entered exactly as I've shown them)
    "File & Print Sharing for Microsoft Networks" must be enabled (Control Panel -> Network Connections > Network > Properties) --- (only needs to be disabled during installation period)
    Administrator password (or administrative user used to install) cannot be blank.
    The Remote Procedure Call (RPC) service needs to be running on the target.
    The Remote Registry service needs to be running on the target.
    The RPC Locater service should be set to "manual" and need not be running. "


    The firewall is set by GP for all machines in our OU's and doesn't cause any problem on 99% of machines.

    Let me know if you get any further.
    cheers
     
  3. murdamcloud

    murdamcloud Registered Member

    Joined:
    Jul 30, 2007
    Posts:
    19
    Ok so now I managed to get the .exe installer to work by directly double clicking it-just doesn't want to work via script. At least the machines are protected for now.

    Need to work out the problem. On some machines I do get an unable create an IPC$ share. Then it gives exit code 3.
     
Thread Status:
Not open for further replies.