EPO Agent install not working?????

[l9nux]

I'm running EPO 2.5 on a Windows 2000 Adv Server (SP2). I can't get the agent to install on any Windows 2000 Pro computers. A messsage appears on the client to say it needs a reboot, but when it does nothing happens and no epoagent folder either.

In the Server Events, all it says for that client is Push Agent install program to \\computername failed.

Am I doing something wrong here? I don't understand why this isn't working. In fact, I did manage to get an agent on one computer, but it won't take any changes and the tray icon no longer appears.

I'd be grateful if anyone can help!!

 

[darrnic]

Do you have file and print sharing turn on in the network configuration on your Windows 2000 Pro workstations? This is needed for the ePO agent to find the workstation. We do not turn on file and print sharing, so this is why I ask.

Secondly, what local user security do you have set? The logged in user must have local admin rights for the ePO agent to install.

The next thing I would do is check the event log on one of the Windows 2000 Pro workstations and see if there is any messages relating to the ePO install. That might give you an idea what is going wrong.

Good luck.

Mary Pierson
mkpierson@cnasurety.com

 

[Guest_imported]

Hi

You don't need to turn on File/Print sharing on your workstations, this is only needed on W9x+ME systems.

Secondly, your local users don't have to be local admins, this will be taken care of the account you installed ePO with... or, the account you defined when pushing the agents out.

It seems to me that your account used when installed ePO dont have sufficent right on your desktops.

Try and create a agent install package and do a manual install on a workstation. If you have communication between the server and W2K, presto... you have at least a working connection.

 

[darrnic]

AV_Dude

In our testing we had to have the file/print sharing turned on to push to W2K clients. This is set by default in W2K. We deliberately turn it off as we don't want all our W2K PCs shown in our network browse list. If they don't show in the network browse list so they can be added to the ePO directory, we were unable to push the client through ePO. Just adding a computer manually and trying to push the ePO client to that computer didn't work for us. Once we turned it on, then we were able to push the client through ePO. Since we have the epoaginst.exe in the login script, it didn't really make a difference to us.

To run the SuperDATs or xDATs, the client has to be a local admin or the SuperDaT or xDAT will not run no matter what user account you use to install ePO. We had plenty of difficulty with this issue in our environment. If you are just running the incremental updates or the zip files, then they don't have to be local admins.

 

[jason2790]

Noticed that EPo management console needs time to 'register' changes in the domain (30-45 minutes from where I sit), and we're 100Mb/tx all around, EPo server has dual 1.6GHz cpu's, 1Gig ram...so it must be the software
that takes it's time...sometimes longer to register 'changes'in policies. Management edition was actually quicker for acknowledging domain wide changes/responses from the client pieces! So much for SQL speed...

 

[AVDude]

Darrnic

I'm a bit surprised that you need to have File/Print sharing enabled on you W2K machines?

Normally this is not a must if you have used an account (in ePO) that has local admin rights on your workstations (normally a Domain Admin Account). This account will use the rights to install the ePO agent and after that do things like installing new software, updating and upgrading without the local user having any rights at all. This is the basic functionality of ePO... Let the AV admin take full control and the user none.

When using poaginst.exe in a logon script the agent will first try to install on the local (logged in user) rights. If this fails, the agent will use the account defined when the agent installation file was created.

Regarding to your problems when trying to install a new S-DAT, what version of VirusScan are u using?
All tasks communicated from ePO to the agents will be carried out on the same rights as above, the agent will use the rights of the account in ePO, or in your case the account defined when the agent was created.

You have in VirusScan 4.5.1 the possibility to select "Update scanning engine if newer scanning engine exists". This mean that if a newer S-DAT are in the local update share or on the McAfee FTP site the agent will pull down the new S-DAT and upgrade.
No need to schedule any Upgrade tasks anymore

AVDude

 

[AVDude]

Opps... My bad

It appears that file/print sharing is a must.
We have it turned on in our network, so I never really tested without it.

It seems that ePO is unable to create a temp directory in admin$ if file/print sharing is off.

So in conclution this must be a W2K issue, not ePO/McAfee.
Cinda looks like the issue with W9x...

AVDude