Version upgrades from RAS

I know Eset haven't released any PCUs for v3 and v4 yet and appreciate the reason given but, I was just curious..... If you have all clients pulling definitions from an internal RAS installation, is there anyway to manually do an internal corporate PCU from RAS without having to manually push out an installation package? I'd prefer not to mess with the GPO and the likes so, I was thinking of a method other than this one.

I note from the ESET NOD32 Antivirus Forum that v4.0.422 should be out at the end of the week and was looking for a slightly easier roll-out method (after some lengthy internal testing obviously!)

~M

 

I dont know the answer to your question, but I want to know the same thing.

I need to update over 200 clients from version 4.0.314 to 4.0.424 and it would be handy if they can pull the program updates from our server as they currently do pattern files. The server is configured to publish program updates, but I cant see how to place the updates in the appropriate location.

 

You can always rebuild a deployment package from the remote install tab using the latest build and push it out that way.

GPO at startup is still the best way to do it in my opinion, since you won't have to force a reboot while the user is logged in or try to schedule machines to be on while you do it.

 

Smacky, do you have any notes or guides on how to set this up in GPO?


Jim

 

Are you familiar with deploying software through a GPO in general, or do you just need the special instruction on how to do Nod32 specifically?

 

a bit of both really. I'm familar with GPO in general, and have quite a few policies defined, but have been unsuccessful with software deployment.

If you have a few moments?.....


Jim

 

First thing you want to do is set up a package distribution point from whatever fileserver you are using or will build for the purpose. Make sure you think out the naming/tree scheme ahead of time because moving files or renaming folders after software is deployed can be a very bad thing since the computers that have the software installed will not be updated. I tend to use the scheme \\[fileserver]\[packageshare]\[Vendor]\[Product]\[Version]\. The share itself needs to allow read permissions to your Domain Computers security group along with full control to your administrators/domain admins group. Then verify that the tree's NTFS permissions grant the same rights.

Download the Nod32 .msi package (packages if you are going to deploy 64-bit builds as well) and place them in the correct directory in your software distrib share. Open the Eset Configuration Editor from your Remote Admin Console and go through and build what will be the default configuration for clients when they first install. Save this file to the same directory that you saved your .msi file(s) and name it cfg.xml. The .msi packages are coded to look for a cfg.xml file in its same directory and use it for configuration data.



In the group policy management console, create a new policy and assign it to the OU with the computer objects in it that you want to install Nod32 on. Edit the policy and go to Computer Config, Policies, Software Settings, Software Installations. Assign a new package to install and navigate to your .msi packages via the UNC path. Don't use a drive mapping as the system account on the other computers will not be able to resolve that drive mapping and this won't work. After that, choose the option to do an advanced deployment. Under the general tab, I recommend changing the name to something more informative than the default (ex:Nod32 [Build #] [32/64-bit]). Under the Deployment tab, go to Advanced and uncheck the box Make this 32-but app available to Win64 machines (assuming you are deploying the 32-bit build). Hit okay when you are done to commit the changes to the policy.



After that, machines in that targeted OU should install Nod32 after their next reboot during the startup cycle.

e: Side-note, I checked the box about ignoring language defaults which is normally disabled by default. You do not need to check this box, but I do it out of habit because Quicktime continuously screws up their .msi packages by not setting English as the default package language which causes policy deployments to fail. That checkbox overrides that behavior and checking it can be a good habit if you are going to work with other products.

 

Fantastic, very much appreciated. Exactly what I needed!

I owe you an e-beer!




Jim