Consolidating configuration files

[andrator]

I'm looking into methods to consolidate configuration files. Currently I have about six different configurations like management server, workstation, terminal server, domain controller, sql2000 server, iis server, exchange server and applications servers.

Method 1:
One method is to create six different configuration files. This means these files share a lot of configuration items like general, amon and update settings. For every item that changes I have to update all the files. The number of configuration files is very likely to grow.

Method 2:
Another method I'm considering is to create one default configuration that consolidates all the similar configuration items (general, amon, update) into one file. Use this to install NOD32 and afterwards use a small configuration file to implement server specific configuration like exclusions, xmon etc. With this method I only have to maintain one general configuration files and one server specific configuration file. These files can then act as documentation for all the configured settings.

Method 3:
Another approach is to use method 2 and merge the general and specific xml files into one xml and use this to install NOD32, but this requires too much knowledge of xml.

I'm currently investigating method 2. Are there any issues I need to consider for implementing this method or are there better alternatives?

[alglove]

I have experience using the NOD32 Remote Administrator. Method 2 seems like a good approach to me. :)

[andrator]

Thanks for the reply :)

[YeOldeStonecat]

What I do...is create my config files in the config editor..and save them. Start with one all purpose config...and save it..this is your starting point, or template. Now..open it..and customize it towards one purpose..say "Workstations". Now..save it under that name...say.."workstations". Now..open your template file..customize it for another purpose..say..."laptops". Now save it under that name. Repeat process based on how many different configs you'd like...another one may be "servers".

I'll usually have workstations set with my usual settings...reporting to the remote admin server, updating via http from the RAS mirror. The laptops will have a similar file...only difference being they will get their updates automatically from Esets internet servers instead of the RAS mirror. Servers will be similar to workstations..except they will not auto-update programs...I wait to do those manually. And naturally IMON is disabled.

I then create the custom install packages...import the configs for each one..and name those install packages accordingly.

Now do your push installs.

Each time you need to make a change to the config...open it up..make your changes...and save it. Then update your push install packages with the updated config.

I find this method works easiest.

[andrator]

Thanks for the advice. I now think I have concept that suits my needs:

One all purpose config that acts as a template.
A few general config files like workstation, notebook and server.
Custom install packages based on workstation, notebook and server.

Per server role (domain controller, sql2000, exchange) a small config file which contains exclusions and non-standard setting like XMON.

Question: should I install EMON and DMON on all servers including e.g. domain controllers even if Outlook never will be installed on this server. The benefit is that I can keep my installation packages as standard as possible.

[alglove]

There is little to no overhead if you leave EMON and DMON installed, so it is fine to leave these components on all your systems. Plus, DMON will scan the occasional ActiveX applet that may make it onto your server as part of a Microsoft update or other software installation.

[YeOldeStonecat]

Yeah on the servers on smaller networks I usually don't even make a config for them....I just push an install..then sit and configure it manually, I mean really...from a default install setting to the settings I prefer...really only takes about 25 seconds to configure the client. Just remember...when pushing out new configs as you tweak them...leave the servers out of the group you push.

DMON and EMON...I just leave them. They're not being used, and really don't take any resources. Harmless to disable them...not going to make a difference...but not a worry if you leave them enabled either.

[andrator]

Nice to know DMON also scans ActiveX applets. Especially on a Terminal Server with internet access.

We now have 15 servers, so I favor not configuring it manually. Besides I'm trying to work more according to ITIL and ISO 17799 standards. For my company it's probably only a matter of time before ISO 17799 becomes mandatory.