Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ePO 2.0

Status
Not open for further replies.

07974

Technical User
Feb 5, 2002
18
0
0
US
We are currently testing ePO to use as our Virus defence management product and after reading all the sites about how good it was and how much it can do, I was looking forward to using it. I have now discovered that alot of things cannot be done fully using ePO, we are going to have to use scripts to pull down updates and to copy them to our DC's all round the country and I have been told we need a dedicated box running Virus Scan to deploy all the updates to workstations, surely this is the whole point of ePO and it must be able to do all this, can anyone give me some input or pass on their experience?

Thanks in advance.
 
Where did you get the idea that you need a dedicated box with VirusScan to push out updates? I have managed this without having a dedicated VirusScan box. (see my posts)
You simply need to have the latest updates (DAT file in a zip, or sdat####.exe file which updates the engine AND dat file) in a folder on your ePO server, or any server for that matter, and point the UNC of the task scheduled for your clients to a shared folder on that server that contains the updates. PLUS (it took me a while to figure this one out) you need the update.ini file that is supplied with each new update. place this in the same folder.
The task from the agent will go and fine the upodate.ini file, and will use this to figure out which update to run, and input variables as needed automatically.

Will
 
Thanks for your response will, You have proved what I have been trying to tell the bloke I am working with. Theway in which we are proposing to implement this solution is to manage our network (spans the whole country) via ePO, when I found out that scripts were going to have to be used here and there I was dissapointed. We plan to have all DC's for the whole country point to the ePO server for its updates which we will place in a share on the ePO server and the rest of the servers and clients at that site will get their updates from a share on the DC's. Can you give me any input from your previous experience or do you think this will run smoothly?

Thanks again in advance
 
No problems! :)
I have two sites, one in the UK and one in Spain. We are currently managing to have the clients download the latest update from the shared frolder on the ePO server (only 6 DCs). Pointing the task to the UNC \\server\share\folder works smoothly, as long as the update file, and the update.ini file are in this location. WIth this set up, I can imagine things would run smoothly regardless of size and complexity of network, just as long as the UNC path is valid on the clients, which you configure at the ePO server in the task...
ANyway, along the lines of scripts, I still haven't managed to find a suitable solution to grab the updates from NAI and store them in the shared folder on the ePO server! Highly annoying.
There is a specific task that can be used for this purpose (Mirror Site Task), but although I have entered all the info correctly, it just doesn't work.
If you have any ideas that I haven't thought of, I'd love to hear them (see my new thread question). I am next going to try to use one of the other servers (I'll explain why if it works) to do the same task, and store the updates on the ePO server via the same shared UNC path.
I'll keep you updated.
I have also successfully managed Force-Installs of new VS software on new clients without much difficulty.

Will
 
Hi 07974 and Will

If you want an ftp script to pull down the updates from NAI I have one I put together about 6-8 months ago and use it at least every week to grab the files from nai and deploy them on a local ftp site.

scripts posted as an tip on thread38-208680

I then have a CNAME record on my DNS server to the site and point all the clients to this. The updates are then done on each client machine when the service starts and every server is configured to update every day, With this in place the updates are done in seconds with no extra traffic to the Internet created. this way I can get dat updates out to my network within a matter of minutes of them appearing on the NAI update site if need be, or I can hold them on a test site and run the updates with lab machines before releasing the to the network if the update is not considered urgent. This way I have avoided any problems with the dat\engine compatability and not had a virus get beyond the point of entry in two years.
I have not got to grips with ePO yet and use this method to update 4 sites on a almost daily basis.

Chris.

 
Thanks for your idea's guys, I would also like to know if either of you use Domino as your mail server. We do, and so far this has caused us the most hastle, mainly because I don't know too much about Domino but I think, also, the DAT update files are different. We hoped it would be teh same DAT file for NetSheild, VirusScan & Groupsheild but I don't think it is.

We are currently testing ePO so we are still messing around with groupsheild for domino but would appreciate any input from anyone who has used domino.

Cheers
 
Hello 07974,

We use Domino, but we have stayed away from GroupShield, and simply use NetShield on the server. Have had no problems with the DAT files or engine on our mail (DMino) server.

Will
 
Hi Will

Do you not lose certain functionality when you use this to protect domino servers, My understanding of Domino is that you need comprehensive protection on its many databases or you leave yourself open to mail virus'

Thanks for your response, I will no doubt be posting many more threads up here once we start rolling it out!

Cheers mate
 
Hi 07974,

Here's the deal:
1) Our ISP (Star) is our first line of defence on email viruses, and this is a 99.9% guarantee from them by contract.
2) Our 2nd line of defence is the NetShield on the Domino server.
3) Groupshield is HEAVY on resources, and even with a <100 person worldwide network, and thus <100 mail accounts, our DOmino Servers were slowed considerably, tended to keel over often, and crash because of Groupshield.

That's how we work here (the system was implemented before I got here), and we have few problems. And have never had a virus infection.

Anyway, if I can offer any assistance, don't hesitate to ask! :)

Will
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top