A mass rollout in the scope of this topic is any case where the product is rolled out to more than 5 to 10 machines and this rollout is to be automated. This is described first in this article. A special case may also be where remote offices shall receive exact same copies of the product (and configuration settings) but where some minimal operator intervention is acceptable. This is described in the second half of this article.
The common thing among mass rollouts is that the effort required to set up the files for unattended distribution of the configuration file and product executable is less than doing the tasks manually. For less than 5 systems, it is often more economical to repeat the configuration on each machine – but this depends on the number of rules and their complexity. Please note that you can also export and re-import configuration settings, so a hybrid solution may be the best when a lower number of machines is to be installed (normal interactive setup plus import of pre-created configuration settings).
Before considering a mass rollout, be sure to read "The WinSyslog Service". This covers necessary background information and most importantly the command line switches.
The basic idea behind a mass rollout is to create the intended configuration on a master (or baseline) system. This system holds the complete configuration that is later to be applied to all other systems. Once that system is fully configured, the configuration will be transferred to all others.
The actual transfer is done with simple operating system tools. The complete configuration is stored in the the registry. Thus, it can be exported to a file. This can be done with the client. In the menu, select “Computer”, then select “Export Settings to Registry File”. A new dialog comes up where the file name can be specified. Once this is done, the specified file contains an exact snapshot of that machine’s configuration.
This snapshot can then be copied to all other machines and put into their registries with the help of regedit.exe.
An example batch file to install, configure and run the service on “other” servers might be:
copy \\server\share\winsyslg.exe c:\some-local-dir
copy \\server\share\winsyslg.pem c:\some-local-dir
copy \\server\share\Microsoft.VC90.CRT.manifest c:\some-local-dir
copy \\server\share\msvcm90.dll c:\some-local-dir
copy \\server\share\msvcp90.dll c:\some-local-dir
copy \\server\share\msvcr90.dll c:\some-local-dir
regedit /s \\server\share\configParams.reg
net start "AdisconWINSyslog"
Please note: These files are needed if you are using WinSyslog 12.0 and above. If you are using a older version, you additionally need the files "libeay32.dll" and "ssleay32.dll".
The file “configParams.reg” would be the registry file that had been exported with the configuration client.
Also, in this file, the service name can be changed to a different name if needed. When the configParams.reg is imported, then the service name will be set as specified in the Windows Services snap-in.
Of course, the batch file could also operate off a CD – a good example for DMZ systems which might not have Windows networking connectivity to a home server.
Please note that the above batch file fully installs the product – there is no need to run the setup program at all. All that is needed to distribute the service i.e. winsyslg.exe and its helper dlls, which are the core service. For a locked-down environment, this also means there is no need to allow incoming connections over Windows RPC or NETBIOS for an engine only install.
Please also note that, in the example above, "c:\some-local-dir" actually is the directory where the product is being installed. The "winsyslg -i" does not copy any files - it assumes they are already at their final location. All "winsyslg -i" does is to create the necessary entries in the system registry so that the WinSyslog is a registered system service.
Branch Office Rollout with consistent Configuration
You can use engine-only install also if you would like to distribute a standardized installation to branch office administrators. Here, the goal is not to have everything done fully automatic, but to ensure that each local administrator can set up a consistent environment with minimal effort.
You can use the following procedure to do this:
Do a complete install on one machine.
Configure that installation the way you want it.
Create a .reg file of this configuration (via the client program).
Copy the winsyslg.exe, winsyslg.pem, libeay32.dll, ssleay32.dll, Microsoft.VC90.CRT.manifest, msvcm90.dll, msvcp90.dll, msvcr90.dll and .reg file that you created to a CD (for example). Take these executable files from the install directory of the complete install done in step 1 (there is no specfic engine-only download available).
Distribute the CD.
Have the users create a directory where they copy all files. This directory is where the product is installed in - it may be advisable to require a consistent name (form an admin point of view - the product does not require this).
Have the users run "winsyslg -i" from that directory. It will create the necessary registry entries so that the product becomes a registered service.
Have the users double-click on the .reg file to install the pre-configured parameters (step 3).
Either reboot the machine (neither required nor recommend) or start the service (via the Windows "Servcies" manager or the "net start" command).
Important: The directory created in step 6 actually is the program directory. Do not delete this directory or the files contained in it once you are finished. If you would do, this would disable the product (no program files would be left on the system).
If you need to update an engine-only installation, you will probably only upgrade the master installation and then distribute the new exe files and configuration in the same way you distributed the original version. Please note that it is not necessary to uninstall the application first for an upgrade - at least not as long as the local install directory remains the same. It is, however, vital to stop the service, as otherwise the files can not be overwritten.