Right now Grinder ships as a single MSI file with everything in it. The installation is pretty straight forward but there are two things to consider first: user account and archive directory.
Because Grinder runs as a Windows service it needs a user account. Further, because Grinder will be moving files around and deleting them it will need a user account that has been granted a few privileges. If the directories you are going to be monitoring are on the local machine and Grinder won’t ever have to access a remote directory then a local user account will work fine. However, if Grinder is going to be working in file shares on remote systems you will want to use a domain account instead.
Grinder needs an archive directory because on occasion bad things can happen. Part of Grinder’s defense strategy is to archive all file before processing them. This way if something bad does happen you can at least get the original file from the archive. The bad thing about this strategy is that if you are handling really big files your archive can get out of hand.
I’m going to assume we are installing Grinder on a development workstation. For the user account create an account named ‘sysop’. For the archive directory I use C:\temp\archive.
With those two details out of the way we can run the MSI. Click through the usual stuff (other than the EULA there aren’t any options). As part of the installation process Grinder will pop-up and ask you for the user account and archive directory. The installer will validate the user account before going on.
When the installer finishes the Grinder service will have been setup and be ready to run. It won’t be started yet though. You can do that through the Services panel applet or the Grinder Service Monitor.