I S S E L - FAQ - Event Scheduler

| | | | |

Using the Event Scheduler with Hit List 4.0

This document is intended to be a comprehensive usage guide to the Hit List Event Scheduler, including troubleshooting when things don't work correctly. However, there are some rare occasions when the Event Scheduler simply doesn't "cooperate", and in those situations running Hit List from the command line using NT's AT Scheduler is the preferred alternative. Instructions on such use are at the end of this document as well as within Hit List under the "command-line" Help topic.

Windows95/98 users:

You must make sure that "enable Event Scheduler" is checked under the Tools drop down menu.

You also must leave the application running (can be minimized on the Taskbar, though) for the Events you've set up to take place (assuming they are scheduled for late evening/early morning when you're not at the computer).

You must set up some Events to run (ie Run Report, Update Database, etc.) by hitting the Event button at the top of the Hit List main screen and entering the correct information.

You should test a few of these to make sure things will run while you watch them (rather than trusting you have every setting completely correct in the absence of testing) so to ensure success for nightly events run when you're not there.

Windows NT users:

Under Windows NT, you can allow Hit List to run invisibly in the background as an NT Service, making it easy to schedule reports, database updates, etc. with Hit List's Event Scheduler.

Requirements for success (NOT OPTIONAL!)

1) You must have INSTALLED Hit List as an NT Service when you ran Hit List Setup. If you did not do this, you need to re-run Setup.

2) You must make sure that "enable Event Scheduler" is checked under the Tools drop down menu.

3) You need to "browse" the NT account (in Control Panel/Services/Marketwave Hit List Service) you intend to use with the Hit List NT Service to pull the correct information out of the NT User Manager (and from your likely NT Domain setup). When you pull up the settings for the Hit List NT Service in the Control Panel/Services applet, there is a small button just to the right of the "This Account" setting - click it, and select the appropriate NT Account from the User Manager (will be displayed) by highlighting the NT Account you want, then clicking Add and then OK. Now enter the appropriate password and confirm it, then click OK.

4) IMPORTANT - Go to Start/Programs/Administrative Tools/User Manager. Now go to Policies/User Rights, check the "show advanced user rights" box and make sure that the NT Account the Hit List NT Service is using (selected in (3) above) can "log on as a Service" and if it can't, make sure you Add this ability.

5) Make sure that the NT Account you selected in (3) and (4) has rights to the webserver(s) over the LAN, to ensure that it can load logs into its database as an NT Service. This means you need to talk to the NT Admin (if that's not you) or your NT Domain administrator to verify that the Hit List NT Service "account" has rights to get the logs, pull them over the LAN and load databases locally (if using an Access back end database - if SQL Server or Oracle, make sure you can in turn connect to the SQL Server or Oracle setup using the same Hit List NT account).

6) Note also that you cannot assume drive letters to mapped network drives when running as an NT Service. When accessing network drives, we strongly suggest using UNC paths instead of drive letters (e.g. \\LogMachine\LogShare\Directory\IN*.LOG instead of Q:\directory\IN*.LOG). This means that Hit List (whether run from the GUI or Service) will always be pointing at the right machine(s) for the logs and their location(s).

7) Now, test a few scenarios to make sure you've set things up correctly. Run a report, update a database, perhaps run an optimize, using the NT Service. If at this point you are unsuccessful, you won't be successful when not supervising things, so re-check 1-5 THOROUGHLY before proceeding. For example, if you are the NT Admin discussed in (5), make sure you actually VERIFY rights across the network as discussed above, don't "assume" the account has the NT rights it needs, do test it. Networks can be changed out from under you without your knowledge by someone else and it may have nothing to do with Hit List, yet your reports still won't run and databases won't update.

Other Troubleshooting/configuration hints

8) If problems persist, also add "act as part of the operating system" in a similar manner to (4) above, save changes, reboot and test again.

9) Optional - Check "Start when the system boots" - This tells Windows NT to automatically start the Hit List NT Service when the machine starts. As a service, Hit List will be running invisibly.

10) Optional - Check "Logon as the system account" - If all of your log files and databases are on the same machine as Hit List, you may use the "System Account" to start Hit List. Using this account means that Hit List will have NO access to any network drives, however, so it's usually not recommended. By default, Windows NT Services do not have access to networks generally.

11) Email cannot be sent via Microsoft MAPI when running as an NT Service using the System Account. POP/SMTP mail has no such limitation. This likely only applies to your situation if you have scheduled Hit List reports that email various recipients when they are done. We have found that POP/SMTP is generally much more reliable than MAPI in nearly every situation, and highly recommend that you simply use POP/SMTP in every situation possible.

12) Check to make sure whatever backup utility you use is NOT running when you try to execute Hit List events, AND that it exits cleanly (so as to prevent NT File-sharing violations that might prevent a Hit List event from firing off correctly). We have seen from time to time with some customers that their backup utility still is "hanging on" to a file (ie the Hit List reports database, the Hit List logfile database, etc.) and thus Hit List's Event can't run due to an NT File-sharing violation.

13) ftp transfer of log files - if you are FTPing logs at some point during scheduled Events, ie database updates, make sure that your FTP path is correct, that the username/password combination is correct, etc. to ensure that it works properly. Also, make sure no one (ie your ISP) is changing things on their end without you knowing.

14) DISK SPACE - Make sure you have plenty of disk space for your database as well as the transfer of the logs to your computer from the webserver(s) at issue. If you run out, Hit List can't make the database any bigger, let alone load the logs.

15) Insufficient RAM/Resources - make sure that you have plenty of RAM on the machine for what it needs to do - ie if you are loading 100mb/daily logs, don't use a machine with only 64 mb RAM, increase to at least 128 mb, or better yet, 256 mb RAM.

16) Complicated reports - Don't run the "long" reports at the start of your queue, run them at the end. Thus, if you are running Path Analysis, put it AFTER Executive Summary, the database update, etc. in your scheduled events. Thus everything will have ample time to complete.

17) "Optimizing a database" events - while using the Hit List NT Service to optimize your database as a scheduled Event is a good idea from the standpoint of database size and speed maintenance, some users have reported that these events prevent others from running. Thus, they should be placed at the END of the queue, or run at other times when there isn't anything else being run on the machine (ie Saturday afternoon, etc.).

18) If you are using a "run report" event to "run this report for each Virtual Server", make sure this report is NOT set to "update the database before running this report". This will save considerable time in running the report's contents for each virtual server, and on larger sites with many, many virtual servers this will avoid having multiple unnecessary database updates (assuming all the virtual domains are being tracked in ONE database. It is highly recommended to use a "dummy" report (see #19 below) or an "update database" event to update the database as a separate event.

19) Using "dummy" reports for updates. You can use a "dummy" report to update one or multiple databases, with each such report aimed at a different database. Usually what you would do in this situation is:

Make a copy of a report like Executive Summary, then highlight the copy and rename it something like "Server 1 Updater". Now hit Design and delete out all the elements excepting the text elements at the top of the report and the Total Number of Requests element (you need at least one calculation or this method won't work). At the bottom of the Outline tab, check the box "update the database before running this report".

Now go to the Output tab and uncheck the HTML checkbox (so you won't create a report output at all - you might consider having an email sent to you here to simply notify you that an update has happened as an alternative).

Now go to the Logfiles tab, override the settings if needed and browse to the logfiles, click on one and then when back on the tab, change the far right end of the path to a wildcard (ie c:\winnt\logs\access*).

Now go to the Database tab, browse to the folder where you want the database to be created, name it, .mwd and then click Open.

Now go to the Updates tab and override the settings if desired, then fill them in.

Now hit OK. Whenever you run this report, typically as a scheduled Event (or manually) it will pull logs from the chosen location and update the chosen database. You can then point other reports at this database to gather data on that set of logs/webserver.

20) Using "old" reports imported from a different version of Hit List. You can use "old" reports from different/older versions of Hit List that you may have used up until now with that other Hit List installation, but MAKE SURE:

You have properly imported such reports into the newer version of Hit List that you're using, and that they work when run manually, and;

You "redo" the Events in the Event Scheduler to properly reflect your "new" imported reports, and test one or two at least once to make sure they run correctly as Scheduled Events.

Worst Case Scenario:

In VERY rare cases, Hit List may not work as an NT Service on your machine.

This is a work-around procedure to address this, taking advantage of HitList's ability to be run from the command line as well as the AT Scheduler in NT.

Steps:

1) Decide what events you want to run and when.

2) Set up reports (Complete Analysis, etc.) that will generate the information you want AND update the database when run (you can't "update the database" as a specific AT scheduler event as you can't do that from the command line) by checking the box under the Outline tab after highlighting the report and clicking Design.

3) Create a batch file that will contain these events, and put it in a directory easily accessible for future changes, called something like HLEvents.bat

4) Using the HitList command line syntax, enter in the batch file what you want to run. This syntax is included below, but is also included in Help\Index\Command-Line - Remember to put the full DOS path into the batch file statements, ie for the Enterprise Live example immediately below, if the executable is in the C:\Program Files\Marketwave\HitList directory, you'd use something like:

"C:\Program Files\Marketwave\HitList\mwhl40l.exe" /RunReport="Complete Analysis" - the reason for the quotes around the initial statement is to make sure that the space between the words Program and Files is preserved in the path - the command won't likely otherwise work.

Note: When referring to report names, reports at the Desktop level can be simply named (e.g. Complete Analysis) but you must specify the full path to reports within folders (e.g. Summary Reports\Executive Summary). Unlike DOS, do not add a \ to the start of the path.

For Hit List Live:
MWHL40l.EXE {/RunReport="Name of the Report to Run"}
e.g. MWHL40L.EXE /RunReport="Complete Analysis"

For other versions of Hit List, change the name accordingly (ie Professional - MWHL40P, Commerce - MWHL40C, etc.)

If a valid report is specified with the /RunReport option, Hit List will run that report then exit.

So, now you've filled the batch file with the events you want, and have saved it.

5) Now, go to the Services applet in the Control Panel, and make sure that the Schedule service is running, and set to Automatic - this way even if you have to reboot your scheduled events will not thus be forgotten.

6) Now, go to a command prompt (Start\Run\cmd). Just to get an idea of AT Scheduler possibilities (assuming you haven't used it before) type at ? and look quickly at the options you have here. What you'll need to set up (as you probably suspect)is an AT command to run the batch file at a time of your choosing. Of course, you can set this up using more than one batch file as well.

The basic command for the example we've been working on is:

AT 0100 /every:monday,tuesday,wednesday,thursday,friday,saturday,sunday c:\hlevents.bat

This command will run the batch file every day of the week at 1 am. You may be able to use 12 hour time, but it's far clearer to all concerned to use 24-hour time.

After you type this in and hit Enter it should give you back an ID# of the job, which when you want to change it later, you can use the /delete syntax to cancel.

You should also be able to see all AT jobs scheduled to run by just typing AT and hitting Return.

This method should be an effective workaround for the rare occasion that HitList doesn't work as an NT Service. Of course, you'll want to customize the reports you're running by using their Output tabs, elements, etc. but you'd have to do this using the regular event scheduler as well.