Disk Maintenance with Enabler

From EnablerWiki

Created: 29 April 2009. Last Reviewed: 26 April 2012

There are two disk / file system problems that occur regularly in stores (and even HO server) which are the enemy of Enabler:

1. File system corruption (which is resolved by chkdsk /f). This will occur frequently in retail stores because the machines get a hard life, regularly used, staff switching them off etc.
2. File system fragmentation. The small incremental growth that occurs in Enabler database and MDX files makes Enabler machines susceptible to extreme file fragmentation, and this severely impedes performance. This is NOT a flaw in Enabler, it is just a characteristic of the environment.

Enabler v4.46 introduced a new option to the Communications Setup screen to call an external batch file for disk maintenance when nibbler restarts during end of day.

The purpose of this file being run is so that various disk maintenance functions can be run to help eliminate the issues mentioned above. This largely replaces the disk maintenance as part of purge and backup - which since Windows 95/98 hasn't really done anything other than reindex anyway!

This is a very simple mechanism to assist customers in eliminating these issues. There are plenty of 3rd party tools available that customers could use instead, including sophisticated network administration tools etc. This technique makes use of features already in the O/S.

Configuration

Back Office → Local Store Setup → Transaction Processing/Comms → Communications → Select 'Store Server' or 'Tills' → enable 'Restart Nibbler during EOD' → Enter path to 'Disk maintenance batch file'

This field is only available when 'Restart Nibbler During EOD' is turned on and allows you to enter the <path>\<filename> to an external command file that will be run when nibbler restarts during the EOD.

Eg: [\\eee-server\shared folder\batchfile.cmd]. If this field is left blank, nothing will be run, otherwise the command file will be executed and once completed, Nibbler will be restarted.

Sample

An example command file would be something like the one below. It has the ability to send email alerts to head office; it relies on the command line mailer bmail.exe which is freely downloadable to do this. http://www.dataenter.co.at/download.asp

Note: This batch file is a SAMPLE ONLY - customers must adjust to their needs, or seek chargeable support from Magenta Retail to assist them if required.

@echo off

set smtpserver=192.168.1.1
set smtpsender=diskalert@companyname.com.au
set smtprecipient=diskmonitor@companyname.com.au

chkdsk c:
if not errorlevel 3 goto DoDefrag
echo Y|chkdsk c: /f

smtpsend -f %smtpsender% -t %smtprecipient% -h%smtpserver% -s "File System Corruption Found" -mbt "Found file system corruption on %computername% C:"

goto endd

:DoDefrag
defrag c:

:endd

The three SET lines near the top most definitely need to be customised: the SMTP server address needs to be the customer's mail server, the sender address can be any address within the customer's domain, and the recipient address would be the person at the customer's head office who should receive the alerts.

The next step is a read-only chkdsk. If errors are found it schedules a chkdsk /f at the next reboot and sends a simple alert email. If there are no errors it performs a defrag.

The above will work on Windows XP. It may not work on Windows Vista/7 unless UAC is disabled. It should also work on Windows 2003 server. Not sure about Windows 2000, but customer's with Windows 2000 could easily customise the batch file to their requirements.

Other customisations may be required:

• Enabler might not be on C: - in which case chkdsk and defrag need to be changed to operate on the appropriate drive.
• If Enabler is NOT on the Windows system drive, then the chkdsk /f can probably run immediately rather than during a reboot.
• Customers might wish to chkdsk and defrag more than just 1 drive.
• Customers might want to include an automatic reboot after the chkdsk /f, this would be highly dependent on each environment.

Note: the first night this process is run it WILL take a long time as the file system is likely to be highly fragmented. Thereafter it will run much more quickly as the defrag won't have as much work to do each night.

For many clients we would anticipate they would put the batch file on the HO or EEE server and configure Enabler to run something like [\\eee-server\shared folder\batchfile.cmd]. Thus there is no manual rollout of the batch file.

Note: Stores MUST have ONLY read-only access to this share/directory/file as it would otherwise give a malicious store staff member unlimited ability to destroy all tills in all stores overnight! Customer's with differing store environments can include multiple batch files in the directory at HO and use global config to configure each branch to run the appropriate version of the batch file.

The use of a batch file is also an opportunity for clients to copy other files, patches, reports, you-name-it from HO to stores, run other processes in stores, etc... the possibilities are almost unlimited.

Customers could also use this batch file to self-replicate it locally to stores - after the first night or two they could change the Enabler configuration to run the store local copy rather than download form HO every time - but the file is so small that running from HO shouldn't matter.

Customers without WAN/VPN - up to them to deploy the batch file to stores - could be achieved with tweaks to FTP scripts or ISLBatch or manually.