Frequently Asked Questions

In short: yes.

On the "License Options" page in the order process you get a chance to provide the name that will be paired with the license key. It'll default to the same name used for billing/invoicing, but you can supply a different one. That way you can have a license tailored to your customer, yet still have the billing/purchase information associated with your company. What's more, even if you fail to use the license customization field or make a mistake, you can just contact us and we'll issue a replacement license key for whatever name you need.

Out-of-the-box installs of the more recent Windows operating systems (both server and workstation grade) have a number of default settings that prevent collection of event log entries, typically resulting in errors such as "access denied" and "the rpc server is unavailable".

Please read the following article for a checklist of these common gotchas:
http://www.logmeister.com/support/kb/faq.php?id=15

A more comprehensive list of barriers to event log collection can be found in the "Troubleshooting" section of the Help file that ships with LogMeister and EventMeister.

There's a section on Firewall configuration and ports in the Troubleshooting section of the Help document that installs with LogMeister and EventMeister, but here's a brief summary:

Whatever event gathering technology you tell LogMeister (or EventMeister) to use, ultimately it makes use of Windows DCOM. DCOM uses dynamic port allocation, so by default a wide range of ports can be involved. If only the MS software firewall stands between the LogMeister host and the target machines, then you needn't concern yourself with ports because the MS firewall comes with exceptions for remote event log management; just enable the exceptions and you're done (unless you've specifically closed other ports).

If you have a hardware firewall to configure, then the process can be made much simpler by constraining DCOM to a smaller, specific range of ports of your choosing and opening them along with 135 (which always seems to be required). This takes a registry edit on all sides of the connection; consult the Help under the section "Other firewalls" for the procedure here, or the following article also covers it (MS seems to have killed its original articles in the rush to eliminate support for server 2003, even though the procedure applies to much newer OSes too).

http://blogs.technet.com/b/askcore/archive/2014/04/29/how-to-configure-msdtc-to-use-a-specific-port-in-windows-server-2012-2012r2.aspx

If that link has died, the basic procedure is below:

Note#1: Use this procedure at your own discretion and on your own liability. Technology Lighthouse assumes no responsibility for the use of this procedure.

Note#2: Quotes are used below purely for clarity - omit them from your registry edits.

a. Open regedt32.exe
b. Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
c. If there is no subkey titled "Internet", create one.
d. Inside the Internet key, create a REG_MULTI_SZ value named "Ports". Each line of the Ports value should specify a range of ports available to DCOM. For this example, add a single line that reads "3000-3010".
e. Add a new REG_SZ value named "PortsInternetAvailable", set it to "Y"
f. Add a new REG_SZ value named "UseInternetPorts", set it to "Y"
g. Open up TCP port 135 to internal traffic. (It may also be necessary to open up UDP 135)
h. Open up the DCOM port range (e.g. 3000-3010) to internal traffic.

Windows Vista, Windows 7, 8, 10, and 2008/2012/2016 Server provide a new technology for event log retrieval (Windows Eventlog Collection or WEC). This new technology has a number of advantages over the previous retrieval technology, WMI (aka Windows Management Instrumentation):

• Ability to retrieve data from new event log types (e.g. Windows Firewall, Task Scheduler)
• Tighter security configuration (WMI has wide ranging abilities, whereas new event log technology is tightly focused)
• Lower resource utilization.
• Better consistency between operating systems

The option to use this new technology is available when LogMeister/EventMeister version 4 is running on any Windows operating system from Windows Vista or later. The option is labelled "Use Windows Event Log Technology" and is enabled automatically when creating new event log feeds, but may also be enabled for existing feeds via Feed Properties (Event Log page).
It is recommended that you use this option whenever the computer(s) that hold the logs are also running Vista or later (e.g. Server 2008, 2012), however if you select the option for an older system, attempts to retrieve log data will most likely result in an access denied error. If you leave the option UNticked, LogMeister will fall back to using the older but still effective WMI technology.

If you've downloaded and installed the trial, you may receive the following message when LogMeister/EventMeister launches:

"The system date/time appears to have been changed recently. Please make sure the date/time is correct, then reboot your PC to continue using this program."

This can happen if the system clock was changed at any point during the current Windows session, and can usually be cleared by restarting the PC. Note that the system clock need not have been changed manually - it can be changed by an internet-based time sync service for example, or when syncing with the host hardware if running within a virtual machine.

The message cannot appear once the product is running in fully licensed mode. If you are using the trial and a reboot does not clear the problem, please submit a ticket requesting a trial extension key.

1) Take a backup of your existing data. This is not essential, but it is recommended. You'll find details on this in the Help under "Backing up and transferring settings"

2) Quit the front end application and stop the corresponding service via the services control panel. This step should prevent the need to reboot your PC after the installation.

3) Download and install the latest trial version of the software. This is an "over the top" install - you do NOT need to uninstall your existing version first. If the installer requests a reboot of your PC to finish the installation, please go ahead with it - failure to do so could lead to unexpected behavior.

4) The new version will automatically pick up your license name and key and self-register.

In that case the best approach would be:

1. Take a backup before doing anything (this is never bad advice)
2. Close the app, stop the service
3. Do a straight over-the-top install, keeping the existing account and data folder location as for v4
4. After the install open up the app and use File -> Change Data Folder to move the location of the data folder
5. If desired, close app & stop service and use the Windows services cpl to change the service start up account.

With appropriate configuration LogMeister can easily handle text logs that are spread across multiple files, even if the name of the newest file changes on a daily basis. (Note that for text files, it is LogMeister you require, rather than its eventlog-only sister product EventMeister).

A guide on how to do this is in the Help file that is installed along with LogMeister. The topic to look for is:
Working with feeds -> Creating a new standard feed -> New Feed Wizard - Text Log -> Step 1

In brief, the wizard requires that you initially nominate one file as an example to be used for setting up the parsing parameters, but you can then specify that the log actually comes from multiple files, and provide a file spec that matches all the candidates. Each time LogMeister comes to look for new entries, it generates a fresh list of all qualifying files, sorts them by modification date and (re)commences parsing at the appropriate point.

If you need any help with setting up the source feed for your log please submit a ticket or email support@logmeister.com.

This rare error is usually a firewall issue. If you're running with the inbuilt (MS) software firewall, make sure you've enabled the remote eventlog administration exception either via the UI or via (elevated) command line:

netsh firewall set service RemoteAdmin

or

Netsh advfirewall firewall set rule group=”Windows Firewall Remote Management” new enable =yes

If you have a hardware firewall to configure, then the process can be made much simpler by constraining DCOM to a smaller, specific range of ports of your choosing and opening them along with 135 (which always seems to be required). This takes a registry edit on all sides of the connection; consult the Help under the section "Other firewalls" for the procedure here, or the following article also covers it:

http://logmeister.com/support/kb/faq.php?id=5

Finally please make sure the Remote Registry service is running and set to start automatically.

If the leading version number of the product you bought matches that of the latest release, you can update for free. For example, if you purchased a license for EventMeister 4.x, you can upgrade to all subsequent 4.x releases for free.

If you bought a license for an earlier series (e.g. 3.x) then you may still be able to upgrade for free subject to your date of purchase, and failing that you will be able to buy an upgrade license at a much lower price than a regular purchase. To find out what you're upgrade options are in this case, please submit a ticket (or email support@logmeister.com)providing some information that will let us track down your original purchase (e.g. name used for purchase and/or company name, or order reference number, or current name and license key, date of purchase etc)

Yes
If you wish to move your LogMeister/EventMeister installation to another computer you can simply take a backup of your existing data files folder and overwrite the corresponding directory on the target machine. This will only transfer feed and notification settings and data. You will need to manually re-enter preference options such as startup options, etc.

• In the front end app, use File -> Explore Data Folder to open a view on the main data folder.
• Quit your existing LogMeister/EventMeister installation and stop the LogMeister/EventMeister service so that it doesn't change any data during transfer
• Take a backup of the entire data folder (keep a copy of this just in case!).
• Install LogMeister/EventMeister on the new machine, run the front end app and use File -> Explore Data Folder to open a view on the main data folder.
• Quit the LogMeister/EventMeister front end app and stop the service on your new machine. It is critical that you do not miss this step!
• Copy your backup contents into the folder on the new machine.
• Restart the service and run the front end app, in that order.

If you wish to transfer LogMeister to a new PC and upgrade from v4 (for example) to v5 at the same time, we suggest you follow this step-by-step procedure:

1. On the old PC, use File -> Explore Data Folder from within LogMeister/EventMeister. Having done that, quit the front-end app and stop the service.
2. Install LogMeister/EventMeister version 5 on the new machine. During installation you can either take the default data folder location, or set a new one.
3. Run the front-end app on the new machine, and use File -> Explore Data Folder from within LogMeister/EventMeister. Having done that, quit the front-end app and stop the service.
4. Copy the contents of the data folder from the old machine (already opened by step#1) to the data folder on the new machine (opened in the previous step).
5. Restart the service on the new machine, and run the front end app. Your feeds should all be present, however they will initially be empty. Use File -> Import Data From Previous Versions to bring in the existing data from the v4 files.
6. If you use email notifications, be sure to set up the correct SMTP details on the new machine.

The bulk of LogMeister's settings are stored in a sub-directory of the "Application Data" folder that is specific to the account under which LogMeister runs, e.g.

C:\Documents and Settings\<>\Application Data\Technology Lighthouse\LogMeister

A fast way to get there is to use File -> Explore Data Folder. Alternatively, type %appdata% into the Run box off the Start menu, and navigate down thru' "Technology Lighthouse\LogMeister"

To move this to a new machine just follow these steps:
1) Quit LogMeister (and, if it's running, stop the LogMeister service) so that it doesn't change any data during transfer
2) Take a backup of the entire LogMeister directory data directory
3) Install LogMeister on the new PC, then quit and stop the service
4) Replace the entire LogMeister data directory on the new machine with the backup you took from the old machine
5) Restart the service and run the front end app.

This will take care of all your feed and notification settings and data. You will still need to manually re-enter configuration options such as smtp settings, startup options, etc. if you're using email notifications.

You can transfer just about about everything across from EventMeister to LogMeister just by copying a few files:

1) In EventMeister, use File -> Explore Data Folder to open the data folder in a file window
2) Quit EventMeister and stop the associated service (important)
3) Install LogMeister and run the front end app.
4) In LogMeister, use File -> Explore Data Folder to open the data folder in a file window
5) Quite LogMeister and stop the associated service
6) Copy all files and sub-folders from the EventMeister data folder to the corresponding LogMeister data folder.

That'll leave you with a few redundant files in your LogMeister folder but nothing to worry about. You can now start up the LogMeister service and/or the front end app. Note that you will still need to configure smtp settings to allow LogMeister to send email notifications.

If you set a different location for the data folder during an upgrade installation of version 5 but haven't copied over the contents of the old data folder, LogMeister/EventMeister will appear empty on its first run.

There are two ways to remedy this:

1) Install again (no need to uninstall first), setting the data folder back to its former location. Then - after the installation - use the "Change Data Location..." command on the File menu to move the entire data folder to its new location. This command takes care of copying over all the necessary files, setting the new data location for both frotn-end app and service, and restarts the service automatically.

Alternatively:

2) Quit the front-end app and stop the service, then copy over the entire contents of the old data folder to its new location. Finally, restart the service and run the front end app to confirm that everything is present and correct.

Go to the Run box (off the Start menu) and type in WBEMTEST to start up the WMI Tester app.

• Tick "Enable all privileges", then click "Connect..."
• In the "Namespace" box of the connect dialog, type:
  \\\root\cimv2
  [where is the name of the networked computer whose logs are to be read]
• In the "Credentials" section, enter the account name and password you're using in EventMeister to connect to the remote machine, and press "Connect"
• Back on the main screen, press "Enum Instances..."
• Enter the following superclass name and hit OK: Win32_TimeZone

This should return a single record that is the PC's currently assigned timezone. Double-clicking will open it up and you can read off various values, the most crucial of which is "Bias" (the offset from UTC in minutes).

If you're experiencing problems with an event log feed it can sometimes be useful to try WBEMTEST, Microsoft's built-in WMI test program.

To use WBEMTEST on the LOCAL computer:

• Type in WBEMTEST into the Run box off the Start menu to start up the WMI Tester app.
• Tick "Enable all privileges", then click "Connect..."
• Change Namespace to root\cimv2, leave everything else as-is and press "Connect"
• Back on the main screen, press "Query"
• Enter the following query, and press "Apply" SELECT * FROM Win32_NTLogEvent WHERE Logfile='security'

(Note: you can use the names of other event logs in step 5, e.g. application, system etc)

---

To use WBEMTEST to retrieve event log data from a REMOTE (networked) computer:

• Type in WBEMTEST into the Run box off the Start menu to start up the WMI Tester app.
• Tick "Enable all privileges", then click "Connect..."
• In the "Namespace" box of the connect dialog, type: \\\root\cimv2 where is the name of the computer whose logs are to be read
• In the "Credentials" section, enter the account name and password you're using in LogMeister/EventMeister to connect to the remote machine, and press "Connect"
• Back on the main screen, press "Query"
• Enter the following query, and press "Apply" SELECT * FROM Win32_NTLogEvent WHERE Logfile='security'

(Note: you can use the names of other event logs in step 6, e.g. application, system etc)

When you create a new event log feed it defaults to the "real time" event gathering method, making Poll Now redundant. You can change to the polling method either during feed creation (in the event log wizard), or after creation via the Event log page of the feed properties (double-click the feed in the left hand-pane, switch to the Event Log page). Once the polling method is being used, Poll Now is enabled.

Note: Poll Now can also be disabled when the feed itself is disabled. Please ensure there is a is tick in the box next to the feed in the left hand pane.

Starting in Vista / Server 2008, Microsoft switched to delivering event log data with UTC timestamps. If your feed data is showing UTC times instead of local server time, you can define adjustments in the Date/Time tab of feed properties. If you need to propagate the same change to a number of event logs feeds, just edit one of them and use Copy Properties To to propagate the change (more details in the Help).

The "Copy Properties To" facility allows you to edit just one feed, then rapidly propagate the changes you have just made to any number of other, similar feeds. In the case of feed logon credentials, please proceed as follows:

1) Open up any one of the relevant (non-local) feeds for editing by double-clicking or right-clicking and choosing "Properties..."

2) On the Event Log page, supply the new account credentials.

3) Press "Copy Properties To..." and tick the option "Event Logon". Make sure the other fields are unticked, unless you also want to propagate those settings to your other feeds. Now, in the lower half of the dialog, tick all the feeds that are to receive the updated logon credentials. (Tip: you can quickly select all the feeds in a group by ticking just the group itself).

4) Press OK to exit that dialog, and OK again to commit your changes in the feed properties sheet below it. All the targeted feeds will now receive the new logon credentials.

LogMeister v5 (coming in 2016) can receive syslog messages from dedicated hardware as well as computers. Most switches and routers can be enabled to send syslog messages to a nominated server.

Alternatively, if you can configure your devices to write their logs to (for example) a text log file in an area of storage that the machine running LogMeister can access, then there should be no problem getting LogMeister to gather the log data, subject to format.

There are basically three approaches you can use:

1) Export the data from within LogMeister/EventMeister to xml, csv, text or custom file format.
This can be done either on demand via File -> Export To File (see Help, Reports & Exporting Feed Data), or via schedule on the Reporting tab of each feed (double-click feed and switch to Reporting tab).

2) Extract the data directly from the store files. The store files used by both our monitoring products are SQLite databases. A variety of 3rd party tools (some free, others available for purchase) can be used to extract data directly from the store files and analyze/format it as required or even re-import to other database systems. The store folder is found in %appdata%\Technology Lighthouse\EventMeister\Stores, or you can use File -> Explore Data Folder. Each ".sto4" file is an SQLite database and is named after the corresponding feed's ID. A mapping of feed IDs can be obtained via File -> Dump List of feeds

3) LogMeister version 5 (due in 2016) also has the option of forwarding log entries from any source to one or more syslog servers. This is accomplished via the syslog notification type.

There are a few ways to approach this, and they all involve settings on the first page of the Text Log Wizard. If you're starting from scratch then just create a fresh text log feed, otherwise right-click on your existing feed and choose "Wizard..." from the resulting popup menu.

What you do next depends on what other files are present in the directory that holds your raw logs:

If they're the only text logs in the directory, then:

• Tick other files
• Select "By file spec" and enter "*.txt" in the box (or whatever file extension matches your logs)

LogMeister will now parse all new .txt files as they appear. Files that it has already parsed will be ignored (unless their modification dates change)

Alternatively, if there are other .txt files living alongside your logs and you need to filter them out, you may need to use a more specific spec and/or even a regular expression.

• Tick other files
• Now think about the spec you want to use. For example, if your log file names are all of the form logDDMMYY.txt you could use: log*.txt

If on the other hand their names don't have a constant part, e.g. YYYYMMDD.txt then just use *.txt and back it up with a regular expression. For example, the following regular expression matches only files that have 8 consecutive numerical digits in them: ([0-9]{8})

There are a number of platform-specific "gotchas" that can lead to access denied and other errors when gathering events for computers running Vista, Windows 7, 8, 10, Windows Server 2008 (original and/or R2), Server 2012 and Server 2016. They are as follows - in no particular order:

Firewall blocking communications
Microsoft's own software firewall comes with pre-built exceptions designed specifically to allow remote management of event logs. They are of course disabled by default, but they are easy to enable. Obviously you can do this through the control panel applet for the Windows Advanced Firewall (just enable all inbound exceptions relating to remote management of event logs) but the fastest and least error-prone method is via command line:

• Open an administrator-level command shell (either regular command prompt or Powershell)
• Issue the following command:
  Netsh advfirewall firewall set rule group="Windows Firewall Remote Management" new enable = yes
  
  TIP#1: If the above command gives you an obscure error related to inappropriate use of "group", please check the quote characters and try again. Some browsers don't display straight double quotes verbatim, which can cause trouble if you've copied and pasted the line into your command prompt.
  
  TIP#2: On older operating systems, this alternative command may be required: netsh firewall set service RemoteAdmin
  
  TIP#3: Please also note that port 135 is required for event log management traffic. If you have sealed off this port, event log gathering will not be possible. Port 445 may also be necessary if you're using WMI.

If you're not using Microsoft's own firewall, or if another breed of firewall also stands between you and the target machine, you'll have to open ports manually. This is not entirely straightforward as Windows uses dynamic port allocation for the underlying communication protocol (DCOM); however a small registry edit can be used to constrain DCOM to a manageable range of ports. Please consult the following Microsoft article: https://support.microsoft.com/en-us/kb/154596

Remote Registry service not running
In many installations the Remote Registry service is set to "manual" startup, which typically means it is not running. Start the service via the services cpl and also ensure that it is set to start automatically so the problem does not recur at the next reboot.

UAC preventing assignment of necessary permissions
The default configuration for User Account Control strips a remote login of the privileges required to access event logs, even when correct administrative credentials have been supplied. The Microsoft-recommended solution to this is to make a small registry edit that modifies UAC behavior just enough to allow remote access to the event logs via an appropriate account.

Caution: only proceed with this if you are fully aware of the dangers of careless registry modification. If you're not keen on doing this yourself, or if you'd like to read more about this before proceeding, please read the following Microsoft Knowledgebase article (it even contains links which will safely apply the registry modification for you): http://support.microsoft.com/kb/951016

In brief, the modification is as follows:

• Open Regedit
• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
• Add a DWORD value with the name LocalAccountTokenFilterPolicy to the above key, and set its value to 1.

Incorrect Registry permissions
Note: only proceed with this if you are fully aware of the dangers of careless registry modification.

• Navigate to HKLM\System\CurrentControlSet\Control\SecurePipeServers\winreg\AllowedPaths and verify that the following appears within the list of path strings (it should NOT be in quotes): System\CurrentControlSet\Services\Eventlog
• Also check the permissions for the enclosing key HKLM\System\CurrentControlSet\Control\SecurePipeServers\winreg. It is essential that "LOCAL SERVICE" have READ permission for this key.

Due to the enhanced security in more recent operatings systems, there are a number of settings that can stand in the way of succesful log reading. The most common things to watch out for are listed in the Troubleshooting section of LogMeister & EventMeister's Help file, but a customer recently suggested to check the following as well:

• Run secpol.msc
• Go to: Local Policies > Security Options Find "Network Security: LAN Manager authentication level"
• Change Setting from "not defined" to "Send LM & NTLM - use NTLMv2 session security if negotiated"

If the networked servers aren't being found by the netbios search (firewall intervention? network discovery disabled?) then you can always create their feeds en-masse using a csv file, assuming you have a list of all the relevant server names.

From the Feeds menu, select "Create event feeds from csv file" and press the Help button. This will show you the format for the comma separated values (csv) text file. You can prepare the file directly in a text editor, but most people find it easier to use Excel then save it out as a csv.

To specify the log in the file, use the same log name that you would select if you were creating a local feed..

e.g. if you're after the MSI and Script applocker log, you would use:
Microsoft-Windows-AppLocker/MSI and Script

Or for the security log, you would just use:
Security

Format to parse:
MM/DD/YYYY hh:mm:ss AM/PM

RX Match:
([0-9]+)/([0-9]+)/([0-9]+) ([0-9]+):([0-9]{2}):([0-9]{2}) (AM|PM)

RX Transform:
$3,$1,$2,$4,$5,$6,$7

When you're running the front end app, it is able to use mapped drives and can access protected shares that you have logged into earlier in the Windows session. The service however runs in a separate session (even though it's running under the same account) and this session does not inherit mapped drives and credentials from the interactive session. That's the most likely reason why the manual report worked, while the automated one failed.

The solution is usually:
- Don't use mapped drives, use the full UNC path instead, e.g. \\shareddevice\pathtoshare
- If necessary use Configure -> Network Storage Access to supply any credentials necessary for access to the protected share.
- If network credentials are used, a reboot of the machine running LogMeister/EventMeister is sometimes necessary. This is due to a quirk in Windows networking.

There are several reasons why LogMeister/EventMeister may not be able to retrieve event log data from the local PC or a PC on your network. Access denied errors are nearly always down to security issues - incorrect permissions for WMI or DCOM (or both) or intervention by a firewall or similar security software, but more obscure errors can be caused by corruption of the WMI repository.

The first thing to try in such cases is Microsoft's own inbuilt WMI test utility, WBEMTEST. The following link describes how to use this valuable resource:

http://logmeister.com/support/kb/faq.php?id=25

If you don't get any clues from WBEMTEST, try a reboot. Sometimes this can clear WMI faults that have no obvious cause. Failing that, you can try the following articles on detecting and repairing problems with the WMI repository:

http://msdn.microsoft.com/en-us/library/aa394603%28VS.85%29.aspx

You can do that easily with a filter:

1) While viewing a feed, choose "Filter..." from the View menu.

2) Construct a Filter with the rules:

Type equals 'ERROR'
OR
Type equals 'CRITICAL'

Notes:
- The filter can be disabled at any time by unticking the active rules, or by deleting them.
- The same filter can be used for viewing, for report output and for notifications. It can also be used in the "Filter" page of a feed's properties to ensure that in future the feed only collects events of the required type.
- If you want to re-use this filter just select "Save as preset" from the Actions popup menu in the filter definition dialog. You'll then be able to select your new preset as and when required.

Yes. Both LogMeister and EventMeister version 4 onwards can run on, and extract log entries from, Windows Server 2012 (and Server 2008 and 2008 R2).

Yes. We've tested version 5 of LogMeister and EventMeister with Server 2016; they can both retrieve events remotely from any Server 2016 version, and can run directly on a Server 2016 host (provided that the GUI is present).