1.1. Download LOGbinder for Exchange

Click here to download LOGbinder for Exchange.

1.2. LOGbinder Newsletter

Click here to subscribe to one of our newsletters.

2.1. Installing LOGbinder for Exchange

***Note: 24-hour Delay in Mailbox Audit Logs***

According to a recent discovery, the PowerShell cmdlets used for retrieving mailbox audit logs have a flaw that produces inconsistent audit results if used to retrieve audit logs in less than 24 hours.

We informed Microsoft of our findings and they confirmed the bug after their own investigation. They also told us they had no timeline to fix the bug and suggested that users simply request audit logs some twenty-four hours after the event took place. We will continue to work with Microsoft on this issue and hope they do resolve it.

In the meantime, the only way we can guarantee audit trail integrity is if we follow Microsoft’s recommendation and don’t ask for mailbox audit logs for the past 24-hour period. Therefore LOGbinder will not process events until 24 hours after the Last Processed value for mailbox auditing in the input settings (see Configure Input).

If you do not want to have this 24-hour delay, you can turn it off in the options (see Configure Options), but we strongly advise against it.

To see how we feel about this issue, what we are doing to mitigate the impact of this bug and what you can do, please follow our latest communications on this at https://www.logbinder.com/support/ExchangeMailboxAuditBug

Installing LOGbinder for Exchange

LOGbinder for Exchange runs as a Windows service on a server belonging to the same domain as your Exchange environment. It translates audit log entries in Exchange, and outputs them to the LOGbinder EX event log, the Windows Security Log, a Syslog server or Syslog files.

Installing LOGbinder for Exchange involves 3 simple steps. (If LOGbinder has been used on another server in the same environment where it is now installed, refer to the Transferring settings to a new server section below, in order to preserve a complete audit trail.)

• Step 1 – Check Software Requirements
• Step 2 – Check User Accounts and Authority
• Step 3 – Run the Installer

Subsequent sections cover:

• Configuring LOGbinder for Exchange
• Mailbox Audit Policy management
• Monitoring LOGbinder for Exchange

Step 1 – Check Software Requirements

Select Server

LOGbinder for Exchange should be installed on a server belonging to the same domain as your Exchange environment.

Software Requirements

• Microsoft Windows server 2012 or later
• Microsoft .NET Framework 4.8
• Microsoft Exchange 2010, 2013, 2016 (Exchange 2016 is supported starting CU6)

Exchange Auditing Requirements

Exchange has two types of audit logs: Administrator Audit Log, and Mailbox Audit Log. For LOGbinder for Exchange to be able to process audit events from these audit logs, they need to be enabled. Note:

• Administrator Audit Log is usually enabled by default.
• Mailbox audit logging can be managed by LOGbinder for Exchange using the Mailbox Audit Policy Management wizard.

Please visit https://www.ultimatewindowssecurity.com/exchange/ for more information on these audit logs, as well as on how to enable, configure, manage, and use them.

Audit Log Search Poll Interval should be set to no greater than 15 minutes. (See box Audit Log Search Poll Interval for explanation.)

Step 2 – Check User Accounts and Authority

Two user accounts are involved with LOGbinder for Exchange.

1. Your account
   • The account you are logged on as when you install and configure LOGbinder for Exchange.
   • Authority Required:
     • Member of the local Administrators group
       • Windows UAC sometimes interferes with this setting. It is recommended that you use the “Run as Administrator” option when running LOGbinder. You may also need to your account as well as the service account modify permissions to the C:\ProgramData folder as described in the third bullet point below.
2. Service account
   • The account that the LOGbinder for Exchange service will run as. This domain account must be created before installing LOGbinder for Exchange. This account does not need to be a local or domain administrator; the LOGbinder for Exchange service can run in a least-privilege environment.
   • Authority Required: (See Appendix A: Assigning Permissions for details on granting these permissions)
     • Exchange administrator roles:
       • View-Only Audit Logs
       • View-Only Configuration
       • View-Only Recipients
       • Audit Logs (Only needed if using the LOGbinder’s Mailbox Audit Policy management wizard)
     • Permissions to access the inbox of the Recipient (configured under Input), if different from the service account.
     • Privilege “log on as a service” (The installer will set this prerequisite.)
     • Permission to create, read, modify files in C:\ProgramData\LOGbinder EX (The installer will set this prerequisite.)
       • Please note that the ProgramData folder is a hidden folder, and it is not the same as the Program Files folder.
       • This LOGbinder EX folder will be created while LOGbinder is installed.

If outputting to Windows Security log

• Privilege "Generate Security Audit" (SeAuditPrivilege)
• Setting audit policy
  • Windows 2003:
    • Enable “Audit object access”
  • Windows 2008 or later:
    • Enable “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”security option
    • Enable “Audit Application Generated” audit subcategory

Step 3 – Run the Installer

Download and run the installer. On the "Logon Information" page, enter the user account name, domain name and password of the service account (the user account that will run the LOGbinder for Exchange service). The rights outlined above must be granted to the account before running the installer, or else LOGbinder for Exchange will not install properly.

If a dialog box "Set Service Login" appears, then the user account information entered previously was not valid. Confirm the account name and password, and re-enter the information.

Transferring settings to a new server

If LOGbinder was running in your environment before, but it now has to be installed on a different server, the following steps can be followed to transfer the settings to the new server. (Please note that LOGbinder is not recommended to be run on two servers at the same time in the same environment.) This not only saves setup time and reduces setup problems, but this will ensure audit log collection to be continued where LOGbinder left off so as to preserve a complete audit trail:

1. Make sure that on both the source (where LOGbinder was run before) and target (the new LOGbinder server) servers, the LOGbinder service is not running and the LOGbinder control panel is not open.
2. Go to the {Common Application Data}\LOGbinder EX folder on the source server, i.e. C:\ProgramData\LOGbinder EX.
   • Please note that the ProgramData folder is a hidden folder, and it is not the same as the Program Files folder.
3. Copy all *.stg and *.xml files to the same folder on the target server.

2.2. Configuring LOGbinder for Exchange

Configuring LOGbinder for Exchange

Open the "LOGbinder for Exchange" link in the Windows start menu, which appears by default in the “LOGbinder” folder.

To use LOGbinder for Exchange, adjust the settings in the three views: Input, Output, and Service. Settings can be changed while the service is running, but changes will be applied only when the service is restarted. If the LOGbinder for Exchange control panel is closed before restarting the service, the changes will be discarded. On the other hand, if the service is already stopped, the changes are saved automatically.

Configure Input

LOGbinder for Exchange uses these methods to connect to the Exchange server: (a) Exchange Management Shell (PowerShell), and (b) Exchange Web Services Managed API 1.2.

To get started, select the line under Inputs that says "Exchange Server Audit" and click on the Properties button on the toolbar. In the Input window you will need to enter three pieces of information: Powershell URL, Exchange URL, and Recipient.

Figure 1: An example Input

Powershell URL: The URL to access Exchange Management Shell cmdlets (via PowerShell). The default value is “http://” + FQDN of server + “/Powershell”. This should be a server with both PowerShell and client access roles functioning. At the moment you are not able to provide a load balancer here; it has to be one of the actual servers. The Autofill button will use the current server to fill in this value. You might need to change this if you are not installing LOGbinder for Exchange on an Exchange server.

Exchange URL: The URL to access the Exchange web service. The default value is “https://” + FQDN of server + “/EWS/Exchange.asmx”. If the Powershell URL is correct, the Autofill button will try to identify the correct Exchange URL. There should be no certificate error when this URL is opened in Internet Explorer. (If a self-signed certificate is being used, the self-signed certificate will need to be added to the trusted root store.)

Recipient: The mail address used for processing audit logs. This will be the mailbox associated with the user (or administrator) in whose context the Exchange Management Shell runs. If this account is different from the LOGbinder for Exchange service account, the service account needs to have the necessary permissions to access the recipient's mailbox.

The Last Processed box shows the date and time audit events were last retrieved from Exchange. After installing it the first time, LOGbinder starts processing admin audit logs from the time of the installation onward, and mailbox audit logs with a 24-hour delay, that is 24 hours before the time of the installation.[1] For further information on this 24-hour buffer period for mailbox audit events, please see the note and blog on the 24-hour Delay in Mailbox Audit Logs.

If some of the backlog events are also to be processed, the start date can be set in the Last Processed boxes. It is recommended that once LOGbinder is in operation, this date not be changed manually, as it could result in skipping some audit events in Exchange, or double-handling, resulting in events appearing twice in the event log. If the date needs to be adjusted, check the box next to the date, and then the date can be adjusted.

Audit Log Search Poll Interval: It might take a considerable time for the Exchange server to send back the search results. By default, Exchange checks if there are any audit log searches every 30 minutes to 24 hours, depending on the Exchange version. However, this frequency can be adjusted in an Exchange configuration file. Please refer to our blog titled Changing the Exchange audit search poll interval on how to adjust this setting. For LOGbinder to be able to function properly, this should be set to not greater than 15 minutes.

After the LOGbinder for Exchange service has been running, the Transactions list will show a list of audit log searches sent to the Exchange server, the start and end period for which logs have been requested, and the time LOGbinder finished processing the audit logs. This information is read-only. After the Exchange server sends back the result of the audit log search, LOGbinder for Exchange will process the event logs and forwards them to the output(s) specified. (See next subheading.) Once the results are received and forwarded to the output(s), the File Name and Completed columns are populated with the appropriate values. If the audit search request was successful, the File Name will be the name of the XML file that Exchange had returned. It is typically in the format of SearchResult_<GUID>.xml. If there is an error, LOGbinder will give a general description of the error, such as:

File Name message	Reason	LOGbinder's solution
FAILED-ERROR	Exchange returned with a "completed with errors" message for some unexplained reason.	LOGbinder will try the same search again.
ABORTED-SEARCH_FAILED	It is the second time that the same search comes back with error.	LOGbinder will send a warning that this search could not be completed.
FAILED-LARGE_RESULTS	Exchange says that there were too many results in the search criteria, that needs to be restricted or narrowed down to get results.	LOGbinder will try to reduce the search interval and try again.
NOT EXISTS	The file name	LOGbinder will try the same search again.

Configure Output

LOGbinder supports multiple output formats. LOGbinder for Exchange allows output to go to

• LOGbinder EX Event Log: a custom event log under Applications and Services Logs.
• Security Log: the Windows Security log. (Please remember to set the additional privileges as described under the Check User Accounts and Authority section when using this feature.)
• Syslog-CEF: a Syslog server using ArcSight’s Common Event Format.
• Syslog-LEEF: a Syslog server using IBM Security QRadar’s Log Event Extended Format.
• Syslog-Generic: a Syslog server using the generic Syslog format.
• Syslog-CEF (File): a Syslog file using ArcSight’s Common Event Format.
• Syslog-LEEF (File): a Syslog file using IBM Security QRadar’s Log Event Extended Format.
• Syslog-Generic (File): a Syslog file using the generic Syslog format.

At least one of these must be enabled in order for the LOGbinder service to start.

To enable an output and adjust the settings, select it and use the menu Action\Properties, or double-click on the item. To enable it, check the box "Send output to [name of output format]."

Select the "Include noise events" if you want to include these in the event log. A “noise event” is a log entry generated from the input (Exchange) that contains only misleading or superfluous information, such as the events 25190 and 25210 generated by LOGbinder. This option is included in case it is essential to preserve a complete audit trail; by default this option is not selected.

Figure 2: Output properties window

For some output formats, LOGbinder for Exchange can preserve the original data extracted from Exchange, along with details as to how the entry was translated by LOGbinder. Check the option “Include XML data” in order to include these details in the event log. Including this data will make the size of the log grow more quickly. If the option does not appear, then it is not supported for that output format.

For the output format "LOGbinder EX Event Log," the entries are placed in a custom log named “LOGbinder EX.” When the log is created by LOGbinder, by default the maximum log size is set to 16MB, and it will overwrite events as needed. If changing these settings, balance the log size settings with the needs of your log management software as well as the setting for “Include XML data.” In this way you will ensure that your audit trail is complete.

For file based outputs, such as Syslog (File), the output file is stored, by default, in the "C:\ProgramData\LOGbinder EX" folder, or in the folder specified by the “Alternate Output Data Folder” option under File\Options. (See section below on Configure Options.)

Configure Service

To start, stop, and restart the LOGbinder for Exchange service, use the buttons on this panel. You may also use the items in the Action menu, or the toolbar.

Figure 3: Message indicating outputs not configured

Although you can use the Services window in the Windows Control Panel to start and stop the service, it is recommended that you use LOGbinder's user interface to control the service. Before starting the service, LOGbinder will confirm that (a) at least one Exchange server has been selected for monitoring and (b) at least one output (i.e. LOGbinder EX Event Log, Windows Security Log) has been selected.

While attempting to start the LOGbinder for Exchange service, a problem may be encountered—perhaps that the service account does not have sufficient authority. The details of the problem are written to the Application Event Log.

See the Monitoring LOGbinder for Exchange article for more information on how to handle issues that may arise when starting the LOGbinder for Exchange service.

Configure Options

Use buttons on the panel, or the menu File\Options, to change LOGbinder's options.

The Enable 24-hour delay in searching for mailbox audit events option is enabled by default. For further information on this 24-hour buffer period for mailbox audit events, please see see the note and blog on the 24-hour Delay in Mailbox Audit Logs.

The Service Account lists the user account that runs the LOGbinder for Exchange service. This is the account you specified when installing LOGbinder for Exchange. If it is necessary to change the account, use the Services management tool (in Windows Administrative Tools).

If the box “Do not write informational messages to the Application log” is checked, then event “551 – LOGbinder agent successful” (See Appendix C: Diagnostic Events) will not be written to the Application log.

Figure 4: Options window

The Logging options can be utilized for diagnostic purposes if experiencing problems with LOGbinder. By default, the “Logging Level” is set to None. If necessary, the Logging Level can be set to Level 1 or Level 2. Level 1 generates standard level of detail of logging. Level 2 will generate more detailed logging. Level 2 should be selected only if specifically requested by LOGbinder support; otherwise performance will be adversely affected. Both Level 1 and Level 2 logging options will generate log files named Control Panel.log, Service.log, Service Controller.log and Service Processor.log in the Log location folder.

The “Alternate Output Data Folder” specifies the data folder used for the output data. This is the folder where LOGbinder stores output that are written in files, such as the Syslog-Generic (File), as well as the above mentioned diagnostic files. The folder path can be set using drive letter or UNC, if it is a network location. The default folder is {Common Application Data}\LOGbinder EX (i.e. C:\ProgramData\LOGbinder EX). Please note that the Alternate Output Data Folder needs the same permissions as the Common Application Data folder as specified under the Check User Accounts and Authority section .

Status Bar

The status bar will show information about the operation of LOGbinder.

	Displays the status of the service. The image shown indicates the service is stopped (). The service may also be running (), or in an 'unknown' state ().
	Shows the status of the license for LOGbinder. If LOGbinder is not fully licensed, a message will appear in the status bar.
	Indicates that settings have been changed. In order to apply the changes, the LOGbinder for Exchange service must be restarted. If the LOGbinder for Exchange service is running and the LOGbinder for Exchange control panel is closed, the changes will be discarded.

License

Use the menu File\License to view information about your license for LOGbinder.[2] If you have purchased LOGbinder for Exchange and need to obtain a license, follow these steps:

• For Unit/Server Count, enter the number of active mailboxes in your Exchange system. (The minimum number of mailboxes requiring licensing will be filled out automatically by LOGbinder.)
• Press the Copy button, and paste the contents into a support ticket.
• When the license key is received, copy it to the clipboard and press the Paste button.

Figure 5: License window

If you are properly licensed, the license window will display and show that you are properly licensed. If there is a problem, respond to your license request ticket immediately.

 

[1] If this is not the first installation of LOGbinder on the same server, it will continue audit log processing from the date and time it finished its last run with the previous installation. If LOGbinder was installed on another server in the same environment before, you might want to refer to the section above about Transferring settings to a new server.

[2] The License menu might be disabled for a few minutes while collecting information needed for licensing.

2.3. Mailbox Audit Policy Management

An administrator can specify a mailbox audit policy, select groups and/or organization units, and then the LOGbinder service will set mailbox audit policy for the mailboxes in those groups and organizational units. The LOGbinder service will regularly enforce this policy, in case new mailboxes were added to the groups and organizational units—or if the policy had been changed for a mailbox.

Using LOGbinder Control Panel to set mailbox audit policy

To set mailbox audit policy, open the Input properties window, and click on the link “Mailbox Audit Policy.” (The same link is available in the Options window.)

NOTE: If the link in Options is disabled, it is because you have not yet created an Input pointing to an Exchange installation. After creating an Input you can set mailbox audit policy.

The main window (see Figure 1) gives an overview of the existing mailbox audit policy that has been set in LOGbinder. This will be empty if this is your first time setting audit policy. From here, you can (1) specify the audit policy, (2) select organizational units that the policy should apply to, and (3) select Exchange groups that the policy should apply to.

Figure 1: Mailbox Audit Policy settings

Clicking on the "Audit Policy" link will open the Mailbox Audit Policy. (See Figure 2.) Select the actions under the appropriate columns: Administrator, Delegate, and Owner. If you select None, all the other boxes will be unchecked and that type of mailbox access will not be audited.

Click the link “Set default audit policy” to use Microsoft’s default mailbox audit policy. You can continue to adjust the policy to suit the needs of your organization.

A recommendation from LOGbinder: Do not audit Owner access, leave it set to None. Auditing what a user does in his own mailbox will create a huge number of audit events, events that have very little value, and will choke your Exchange installation—as well as the LOGbinder service.

Figure 2: Mailbox Audit Policy

When finished adjusting the audit policy, click on the Close button to return to the main Mailbox Audit Policy window.

Clicking on the "Adjust Organizational Units" link to specify organizational units. (See Figure 3.) The list of all organizational units will be shown in the list. If you wish to apply to policy to organizational units, select one or more items and press the Add to Selected button.

Figure 3: Select Organizational Units

When finished selecting the organizational units, click on the Close button to return to the main Mailbox Audit Policy window.

Clicking on the "Adjust Groups" link will present the Select Groups window. (See Figure 4.) You must first filter groups. Enter at least the first three characters of the groups’ names—then press the Go button. The list of groups that match will show in the list. Select one or more groups and press the Add to Selected button. The Selected Groups list will contain the groups to which the policy will be applied. You may repeat the filtering as many times as needed.

If you press the Go button with no text in the Filter Groups box, then all groups will be listed. This is not recommended if you have a large number of groups.

Figure 4: Select Groups

When finished selecting the groups, click on the Close button to return to the main Mailbox Audit Policy window.

When you press OK, LOGbinder will save the adjustments to your mailbox audit policy.

Enforcing Mailbox audit policy

Every night, the LOGbinder service will enforce your mailbox audit policy. It will find the mailboxes that are contained in the groups and/or organizational units. If the mailbox’s audit policy does not match, LOGbinder will change its policy. LOGbinder will report on the number of mailboxes that have been adjusted. Please note that you must set the “Audit Log” management role to use this feature – See Check User Accounts and Authority section in the "Installing LOGbinder for Exchange" article.

NOTE: For performance considerations, it is recommended that you use as few groups and/or organizational units as possible. The greater the number of groups and organizational units, the longer it will take to inspect audit policy.

2.4. Monitoring LOGbinder for Exchange

Monitoring LOGbinder for Exchange

When installing, configuring, and running LOGbinder for Exchange, the software writes diagnostic events to the Windows Application Event Log. Most of these will be from the source "LOGbndSE" and the category "LOGbinder." You may use the Windows Event Viewer to examine these events.

During Installation and Configuration

During installation and configuration, you will find these entries:

• After installation, there may be an entry from the source MsiInstaller: "Product: LOGbinder EX -- Installation completed successfully."
• When the configuration of LOGbinder for Exchange changes, you will see one or more entries entitled "LOGbinder settings changed." See Appendix C: Diagnostic Events: “553– LOGbinder settings changed” for information about these events.
• When the service starts, there may be an entry from the source LOGbinder EX: "Service started successfully." (Entries are also written when the service is stopped.)

You can monitor these events to ensure that LOGbinder for Exchange continues to be configured properly, and that unauthorized changes do not occur.

After configuring LOGbinder for Exchange and starting the service, it automatically performs a check to ensure that LOGbinder's settings are valid and that the account running the Windows service has sufficient authority. If there is a problem, the LOGbinder for Exchange service will not start and a message will be presented to the user. In most cases, the details of the problem are written to the Application log. Common problems include:

• Input/output not configured properly. See the previous section “Configuring LOGbinder for Exchange” for more information.
• Insufficient authority. If the service account does not have adequate authority, then the service will not run. An entry is written to the Application log. See Appendix C: Diagnostic Events: “556– LOGbinder insufficient authority” for more details. Some of the common missing permissions include:
  • Account does not have authority to log on as a Windows service
  • Account does not have necessary permissions in Exchange.
  • The account does not have authority to write to the Security event log. (If this output destination has not been selected, then it is not necessary to grant this permission.)
• License invalid. If the license is not valid or has expired, then the LOGbinder for Exchange service will not run. An entry may be written to the Application log. See Appendix C: Diagnostic Events: “557– License for LOGbinder invalid” for details.
• Other errors will be found in entries entitled "LOGbinder error." See Appendix C:Diagnostic Events: “555– LOGbinder error” for more information.

If any of these errors are encountered, the LOGbinder for Exchange service will not run.

While LOGbinder for Exchange is Running

While LOGbinder for Exchange is running, you will see information entries in the Application log as follows:

• Entries 'exported' from Exchange. For each Exchange server being monitored, this message indicates the number of audit entries that LOGbinder for Exchange has processed.
• Entries 'imported' into the Windows event log. This indicates that the audit entries have been placed in the enabled output formats. There will be one message event if multiple output formats have been selected (i.e. you have selected both Windows Security Log and Windows Event Log as output formats). The 'export'/'import' entries are complementary: there should be a corresponding 'import' entry for each 'export.'

These log entries are informational in nature. Generally no action is required. If more entries are being processed than what appear in the event logs or in your log management solution, it could be that the log size is too small and entries are being overwritten. See Appendix C: Diagnostic Events: “551– LOGbinder agent successful” for more information on these events.

If LOGbinder for Exchange has an error, an entry will be created in the Application log. If permissions are removed, or if the license expires, you may receive a "556– LOGbinder insufficient authority" or "557– License for LOGbinder invalid" error, which are explained above. Other errors will be entitled "555 – LOGbinder error". If you cannot resolve the problem, please submit the issue to the LOGbinder support team.

2.5. Appendix A: Assigning Permissions

Exchange Administrator Roles

1. Add a new administrator role group, containing the following roles:
   • View-Only Audit Logs
   • View-Only Configuration
   • View-Only Recipients
   • Audit Logs (Only needed if using the LOGbinder Mailbox Audit Policy Management wizard – See Mailbox Audit Policy Management article)
2. Make the LOGbinder service account a member of this role group.

The above two steps can be achieved, for example, through the Exchange Admin Center (https://<hostname>/ecp) interface, or using an Exchange Management Shell cmdlet, such as

New-RoleGroup "LOGbinderEX" -Roles "View-Only Audit Logs", "View-Only Configuration", "View-Only Recipients", “Audit Logs” -Members "lbex_svc"

where lbex_svc is to be replaced by the name of the LOGbinder for Exchange service account.

Local Security Policy Changes

The following chart summarizes the changes to be made in the Local Security Policy. Detailed explanations are found after the chart.

Local Security Policy (secpol.msc) settings summary				Windows Server 2003	Windows Server 2008/2012
Security Settings	Local Policies	User Rights Assignment	Log on as a service	add service account	add service account	This always needs to be set and is configured during installation by the installer
			Generate security audits	add service account	add service account	These need to be set if outputting to Windows Security log
		Audit Policy	Audit object access	set Success	N/A
		Security Options	Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings	N/A	set Enabled
	Advanced Audit Policy Configuration	Object Access	Audit Application Generated	N/A	set Success

Log On as a Service 

• Open the "Local Security Policy" (secpol.msc) Microsoft Management Console (MMC) snap-in.
• Select Security Settings\Local Policies\User Rights Assignment
• Open "Log on as a service" and add user
• NOTE: You can also configure this via a group policy object in Active Directory. If you try to modify this setting in Local Security Policy and the dialog is read-only, it means it is already being configured via Group Policy and you'll need to configure it from there.

Generate Security Audits (SeAuditPrivilege)

• Open the "Local Security Policy" (secpol.msc) Microsoft Management Console (MMC) snap-in.
• Select Security Settings\Local Policies\User Rights Assignment
• Open "Generate security audits" and add user
• NOTE: You can also configure this via a group policy object in Active Directory. If you try to modify this setting in Local Security Policy and the dialog is read-only, it means it is already being configured via Group Policy and you'll need to configure it from there.

Audit Policy

Windows Server 2003

• Open the "Local Security Policy" (secpol.msc) Microsoft Management Console (MMC) snap-in.
• Select Security Settings\Local Policies\Audit Policy
• Edit "Audit object access," ensuring that "Success" is enabled. (LOGbinder for Exchange does not require that the "Failure" option be enabled.)
• NOTE: You can also configure this via a group policy object in Active Directory. If you try to modify this setting in Local Security Policy and the dialog is read-only, it means it is already being configured via Group Policy and you'll need to configure it from there.

Windows Server 2008/2012

Audit policy can be configured with the original top level categories as described above for Windows 2003 but most environments have migrated to the new more granular audit sub-categories available in Windows 2008 aka (Advanced Audit Policy).

Using Advanced Audit Policy Configuration allows for more granular control of the number and types of events that are audited on the server. (NOTE: The steps described here are for Windows Server 2008 R2; see TechNet for information on earlier releases.)

• First, ensure that ‘basic’ and ‘advanced’ audit policy settings are not used at the same time:
• Microsoft gives this warning: “Using both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.” (http://technet.microsoft.com/en-us/library/dd692792(WS.10).aspx)
• Select Security Settings\Local Policies\Security Options
• Open and enable “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”
• To enable LOGbinder events to be sent to the security log:
• Select Security Settings\Advanced Audit Policy Configuration\Object Access
• Edit “Audit Application Generated,” ensuring that “Success” is enabled. (LOGbinder for Exchange does not require that the “Failure” option be enabled.)
• NOTE: You can also configure this via a group policy object in Active Directory.

2.6. Appendix B: LOGbinder Event List

LOGbinder for Exchange Events

https://www.logbinder.com/Products/LOGbinderEX/EventsGenerated

Diagnostic Events

551 – LOGbinder agent successful

552 – LOGbinder warning

553 – LOGbinder settings changed

554 – LOGbinder agent produced unexpected results

555 – LOGbinder error

556 – LOGbinder insufficient authority

557 – License for LOGbinder invalid

2.7. Appendix C: Diagnostic Events

551 – LOGbinder agent successful

This event occurs when LOGbinder for Exchange successfully translates log entries. Usually appearing in pairs, as one indicates that log entries have been 'exported' from their source (for example, Exchange), and the other that entries have been 'imported' to their destination (for example, the Windows event log). This event is informational in nature.

This event is written to the Windows Application log.

Example A

LOGbinder EX exported 3 entries from Exchange site http://MySite

Example B

LOGbinder EX imported 3 entries to Security event log

Example C

LOGbinder EX imported 3 entries to LOGbinder EX event log

552 – LOGbinder warning

This event occurs when LOGbinder for Exchange does not find information as expected. In most cases, it does not indicate a serious problem, but is provided so as to complete the audit trail. This event is written to Windows application log.

Example

This warning indicates that the results of the audit log search have not been returned by Exchange within two hours. If Exchange doesn’t respond to a request, LOGbinder will not retry that range. If the results or an error message is delivered, LOGbinder will handle it while it is in the transaction list (30 days). It will send the message below after 2 hours of not receiving it.

LOGbinder warning
No Response From Exchange – Audit Data Gap

Exchange has not responded to an audit data request in a reasonable time. If Exchange eventually responds with audit data for this request, LOGbinder will process it for up to 30 days. However, this warning indicates that there is currently a gap in audit data.

Request data:

2358359d-6da5-49b3-9132-e41d2d323dc5

Exchange Admin audit search Initiated: 7/7/2016 12:46:21 PM Start time: 7/7/2016 7:21:14 PM End time: 7/7/2016 7:26:20 PM

553 – LOGbinder settings changed

This event occurs when the LOGbinder settings are changed. This event is written to Windows Application log.

For LOGbinder for Exchange, this includes which Exchange servers are monitored, which audit event types are handled, and the date and time LOGbinder last translated log entries. In addition, the settings for output formats are included.

Example A

LOGbinder settings changed
Output to Security log enabled. Noise events included.

Example B

LOGbinder settings changed
Settings for lbex_svc@contoso.com adjusted: Settings ID: 48f7e2f2-4da3-4d59-9b41-507799bedf77

Example C

LOGbinder settings changed
Settings for http://ex1.contoso.com/powershell adjusted: Mailbox audit policy organizational units changed

554 – LOGbinder agent produced unexpected results

This event occurs when LOGbinder for Exchange encounters something unexpected when translating a log entry. At times it may be from a custom log entry.

This event is written to Windows Application log.

You can help us improve LOGbinder by reporting these events to the LOGbinder support team so that the LOGbinder product may be improved. Private data will not be shared.

Example

In this example, the developer used an existing event type, "Workflow," but included non-standard event data.

LOGbinder agent produced unexpected results
As the LOGbinder agent translated this entry, it encountered data is could not handle properly. It could have been caused by a custom or undocumented feature. So that LOGbinder can handle these entries in the future, it is suggested that you submit the entry to the LOGbinder support team.
<LogEntry siteName="http://shpnt" itemType="List Item" userName="Robert Solomon" locationType="Url" occurred="2009-06-29T21:49:11" eventType="Workflow"><RawData siteId="3b7fb82c-f30d-4604-99c0-df8325e9cff4" itemId="c04f5388-bf24-4007-b463-1dd1b3c19a02" itemType="ListItem" userId="1" documentLocation="Cache Profiles/1_.000" locationType="Url" occurred="633819089510000000" event="Workflow" eventSource="ObjectModel"><EventData>http://shpnt/docLib/CopiedFile.ext</EventData></RawData><Details /></LogEntry>

555 – LOGbinder error

This event occurs when the LOGbinder service encounters a problem that needs attention. This event is written to Windows Application log. In most cases this gives enough information for you to address the problem successfully. Otherwise, please contact LOGbinder support for assistance.

Example A

In this example, the error indicates that the LOGbinder for Exchange service cannot run because the Exchange web service has not been configured properly.

LOGbinder error
Cannot start LOGbinder EX service, Exchange web service not configured.

Example B

In this example, a program assembly used by LOGbinder for Exchange does not exist, indicating that the LOGbinder software is no longer installed properly.

LOGbinder error
Exporter assembly does not exist: C:\Program Files\LOGbndEX\MTG.LOGbinder.Exchange.dll

Example C

In this example, a certificate error is indicated. The Exchange URL set for the inputs should open in Internet Explorer without any certificate error. Certificate errors often occur when using a self-signed certificate.

Could not retrieve mail messages from Exchange mailbox. Details: The request failed. The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.; The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.; The remote certificate is invalid according to the validation procedure.

Action: Add the self-signed certificate to the trusted root store.

556 – LOGbinder insufficient authority

This event occurs when the LOGbinder for Exchange service cannot run because of invalid or inadequate permissions. The event will include the module lacking the permission, the name or description of the permission, as well as relevant details. Each example below also includes the action needed in order to correct it.

Example A: No permission to write to security log

LOGbinder insufficient authority
The LOGbinder agent cannot operate normally because it lacks sufficient authority.
Source: Security Log
Privilege: SeAuditPrivilege
Details: The LOGbinder agent does not have the necessary rights to configure the security log

Action: The service account needs the "Generate security audits" privilege (https://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/Generate-security-audits), or do not enable LOGbinder to output to the Windows Security log.

Example B: Attempt to write to security log from invalid location

One measure to protect the security log is to write security events only from authorized locations. When LOGbinder is configured, it registers its program location with the security log. If this error occurs, then LOGbinder had been reinstalled to a different location, and the previous location was not removed properly.

LOGbinder insufficient authority
The LOGbinder agent cannot operate normally because it lacks sufficient authority.
Source: Security Log
Privilege: Invalid Location
Details: Cannot write to because the program location does not match what has been previously configured

Action: Recommended to delete the registry key manually. First ensure that LOGbinder is not open. Then delete the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Security\LOGbndES. Be careful not to delete other parts of the registry, as it can cause the server to be unstable. When you reopen the LOGbinder control panel, it will reconfigure its ability to write to the security log.

Example C: Internal error

LOGbinder insufficient authority
The LOGbinder agent cannot operate normally because it lacks sufficient authority.
Source: Security Log
Privilege: Internal Error
Details: The security account database contains an internal inconsistency

Action: One factor that can cause an internal error is if the LOGbinder program path is too long. By default, LOGbinder is installed to C:\Program Files\LOGbndEX. It is recommended that the default be used. If the software has been installed to a different location with a longer program path, to correct this error it will be necessary to reinstall LOGbinder.

Example D: Log on as service

LOGbinder insufficient authority
The LOGbinder agent cannot operate normally because it lacks sufficient authority.
Source: LOGbinder service
Privilege: Log on as service
Details: Account running LOGbinder agent does not have user right "Logon as a service"

Action: The service account needs to be assigned the "Logon as a service" user right. (https://www.ultimatewindowssecurity.com/wiki/WindowsSecuritySettings/Log-on-as-a-service)

Example E: Cannot start LOGbinder control panel

LOGbinder insufficient authority
The LOGbinder agent cannot operate normally because it lacks sufficient authority.
Source: LOGbinder Manager
Privilege: File Permissions
Details: Account running LOGbinder Control Panel needs to be a member of the local Administrators group

Action: Ensure that the user account used to run the LOGbinder for Exchange control panel has local administrator access.

557 – License for LOGbinder invalid

Occurs when the license for LOGbinder is not valid and an attempt is made to start the service. This event is written to the Application log.

If the license is not valid, the LOGbinder for Exchange control panel continues to operate as normal. However, the LOGbinder service will not start if the license is invalid. Follow the instructions in the control panel, in the menu File\License, in order to obtain a license to the software.

Example

License for LOGbinder invalid
Details: License is invalid. Open LOGbinder for Exchange Control Panel to remedy.

2.8. Appendix D: Troubleshooting

Initial checks

Check the Inputs in LOGbinder for Exchange control panel:

1. If there are entries under Transaction, then the Powershell URL is set good.
2. If the Completed column is filled, then the Exchange URL and Recipient are set good.

Verifying Mailbox Access

(In the following steps, some examples are shown. Please replace the bold parts with the appropriate details of your environment.)

1. Open Internet Explorer and logon as the LOGbinder service account, to the mailbox via Outlook Web Access using the server name specified in LOGbinder for Exchange control panel, such as

   https://ex1.acme.com/owa

   You should see emails in the Inbox or in Deleted Items from Microsoft Exchange with subjects, such as “Administrator Audit Log Search …” and “Mailbox Audit Log Search …”

2. In Internet Explorer go to the Exchange URL of your Input setting, such as

   https://ex1.acme.com/ews/exchange.asmx

   You should get the WSDL xml for Exchange, something like this

   

   Make sure there are no certificate errors in the browser.

   If it doesn’t work, you could try to identify the correct URL by executing the following PowerShell command from the Exchange Management Shell on the Exchange server:

   Get-WebServicesVirtualDirectory | fl *url

Verifying PowerShell Connectivity and Exchange Authority

(In the following steps, some examples are shown. Please replace the bold parts with the appropriate details of your environment.)

1. Double-check what account LOGbinder for Exchange service is configured to Logon as.
2. Logon to the desktop using that account.

Verifying PowerShell Connectivity

3. Open PowerShell – Not the Exchange Management Shell
4. Run (on line b, replace the URL with the correct PowerShell URL):
1. whoami
2. $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://ex1.acme.com/PowerShell/
3. Import-PSSession $Session

Verifying Exchange Authority

5. After the previous steps, run the following commands (on lines c and d, replace the email address with an email address where you want the results to be sent to):
   1. $enddate = Get-Date (Get-Date).AddHours(-24) -Format "MM/dd/yyyy HH:mm"
   2. $startdate = Get-Date (Get-Date $enddate).AddMinutes(-10) -Format "MM/dd/yyyy HH:mm"
   3. New-AdminAuditLogSearch -StartDate $startdate -EndDate $enddate -Name LOGbinder-test -StatusMailRecipients administrator@acme.com
   4. New-MailboxAuditLogSearch -StartDate $startdate -EndDate $enddate -Name LOGbinder-test -StatusMailRecipients administrator@acme.com

6. After sufficient time elapsed, you should see emails in the Inbox or in Deleted Items from Microsoft Exchange with subjects, such as “Administrator Audit Log Search …” and “Mailbox Audit Log Search …”

   Note: Exchange server might take up to 15 minutes (or more) to generate the audit report.

Additional notes

On the server where LOGbinder for Exchange is installed, what version of Windows are you running? Windows Server 2003, 2008, 2008 R2, etc.?

• Windows Management Framework 2.0 is integrated with Windows Server 2008 R2.
• If you have Windows Server 2003 or Windows Server 2008 (but not R2), have you installed the Windows Management Framework 2.0?
  http://technet.microsoft.com/en-us/library/dd335083.aspx

  Note the requirements for Exchange 2010:

  • Windows Management Framework installed
    • Windows Management Framework includes Windows PowerShell V2 and Windows Remote Management (WinRM) 2.0.
  • The fully qualified domain name (FQDN) of an Exchange 2010 server in your organization
  • The domain this server is joined to must be trusted by the domain where the Exchange server resides.
  • TCP port 80 must be open between your computer and the remote Exchange 2010 server, and the port must be allowed through Windows Firewall on the Exchange 2010 server.
  • A user that's enabled for remote Shell

3.1. Versions of .NET and LOGbinder for Exchange Server

Recently (June 2015) we received a trouble ticket from three customers with LOGbinder for Exchange. Two of them were large Enterprise customers. It turns out that if the version of .NET that is running on the Exchange Server, the server where LOGbinder for Exchange is installed and/or the server running the PowerShell scripts is different, the Exchange API is unable to function properly. It took some time to figure it out, but we’ve released a patch that will resolve the problem for the time being. It’s an odd problem to have, and seems to be a problem with .NET incompatibility between version 3.5 and 4.0.

We would be interested to know if you have noticed something similar in your environments where .NET 4.0 is running. Please let us know if you have experienced any .NET 4.0 incompatibility.

3.2. Changing the Exchange audit search poll interval

If you are doing auditing for Exchange server using the New-AdminAuditLogSearch and New-MailboxAuditLogSearch cmdlets, you might have noticed that it takes a while until Exchange delivers the audit reports. You might wonder: How long does it actually take to get the results? Is there any setting that determines this? If yes, can it be changed?

First of all, we must note that Microsoft says that after you run the New-AdminAuditLogSearch cmdlet, Exchange may take up to 15 minutes to deliver the report to the specified recipient. (See Overview of Administrator Audit Logging for Exchange 2010, Administrator Audit Logging for Exchange 2013, and Admin audit logging for Exchange 2016 and later.)

However, in reality you will find that at times Exchange takes significantly more time than that to deliver the report. On Exchange 2013 and later, it can take up to a day. This might not suit the need of all, so let’s see how we can change this behavior.

The value that controls this timing is stored in an XML configuration file under the %ExchangeInstallPath% folder. The file is in the Bin folder, and called Microsoft.Exchange.Servicehost.exe.config. Look for the following line inside the <appSettings> tag:

<add key="AuditLogSearchPollIntervalInMilliseconds" value="…" />

This value determines (in milliseconds) the frequency of audit log searches, affecting both the admin audit log search and the mailbox audit log search. The default value for Exchange 2010 is 1800000 (that is 30 minutes). For Exchange 2013 and later, the default value is 86400000 (that is 24 hours). This means that Exchange 2010 will execute audit log search polls every 30 minutes and Exchange 2013 and later versions will execute audit log search polls every 24 hours.

If you would like to use a different value, you can simply change it in the config file using a text editor. Please note that you have to restart the Microsoft Exchange Service Host service for the change to take effect.

If you prefer to change the value more programmatically, you can do it from PowerShell by running the following script (e.g. to change the interval to 10 minutes):

$cfgpath = $Env:ExchangeInstallPath + "Bin\Microsoft.Exchange.Servicehost.exe.config"
[xml]$cfg = Get-Content -Path $cfgpath
($cfg.configuration.appSettings.add | where key -Match "AuditLogSearchPollIntervalInMilliseconds").value = "600000"
$cfg.Save($cfgpath)

(Again, don’t forget to restart the Microsoft Exchange Service Host service after the change.)

In this article, we looked at how to determine and control the audit log search poll interval in Exchange. As a final note, please mind the implications this setting might have on your CPU usage, if you set the value too low.

3.3. Where to find information about LOGbinder events

Every month we answer about 150,000 questions about events. But where do you go if you have a specific question about an event reported by LOGbinder? Some of our SIEM Synergy partners have collaborated with us to provide a hyperlink within their application to take you directly to the relevant event ID page. So when you see an event you wish to research, clicking on the hyperlinked Event ID will take you directly to the details page on Ultimate Windows Security’s Online Encyclopedia.

But what if your SIEM doesn’t have a hyperlink to the right page? You can still get the information by browsing to UltimateItSecurity.com and clicking on Security, then Encyclopedia. (https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/Default.aspx) Once there, select the source of the event (All Sources, Windows Audit, SharePoint Audit, SQL Server Audit or Exchange Audit). If you want to narrow the list use the drop-down box on the right, else browse the list of events and click on the appropriate one to get the full details. We list the events in numerical order, so they’re easy to find. (By the way, when you get a chance, send a note to your SIEM’s product manager to ask them to finish their integration so you can save yourself the trouble next time when you need the event information.)

If you still can’t find your answer there then click on the blue “Ask a question about this event” button and post your question in the Ultimate IT Security forum. LOGbinder is now sponsoring an Exchange, SQL and SharePoint forum there and you can expect a quick response from one of our technical engineers.

3.4. Exceeding the maximum number of audit log search requests

Amid the many undocumented “features” of Microsoft Exchange server auditing, from time to time we discover new things. This time it is about a limit that is set by Exchange on how many audit log search requests you can execute.

This number seems to be a maximum of 50 asynchronous mailbox audit log search requests (New-MailboxAuditLogSearch cmdlet) and 50 asynchronous admin audit log search requests (New-AdminAuditLogSearch cmdlet). If you issue more than 50 of any of the above cmdlets, you will get an error message like this:

[PS] C:\Windows\system32>(Get-AuditLogSearch).Count 

50

[PS] C:\Windows\system32>[PS] C:\Windows\system32>New-AdminAuditLogSearch -StartDate "2/10/2017 10:00" -EndDate "2/10/2017 11:00" -Name "testing" -StatusMailRecipients testing@test.local

You have exceeded the maximum number of audit log search requests that your organization can submit. Please try again later.

+ CategoryInfo          : QuotaExceeded: (:) [New-AdminAuditLogSearch], InvalidOperationException

+ FullyQualifiedErrorId : [Server=LAB-EX,RequestId=43e8b057-be65-4c4e-9441-64a652efafe0,TimeStamp=2/20/2017 11:01:57 PM] [FailureCategory=Cmdlet-InvalidOperationException] 5776B0C3,Microsoft.Exchange.Management.SystemConfigurationTasks.NewAdminAuditLogSearch

+ PSComputerName        : lab-ex.test.local

After one or more audit log search requests have been processed by Exchange, you can again issue more requests.

The number of counters for admin and mailbox audit log requests are separate. In the above example, we have reached the maximum number of admin audit log search requests, but we have not issued any mailbox audit log requests. Therefore, we can still issue New-MailboxAuditLogSearch cmdlets.

Also, the above limits only apply to asynchronous audit log requests, so in the above example you could still issue Search-AdminAuditLog cmdlets and get the results.

From our testing so far, this applies to most (if not all) cumulative updates of Exchange 2013 and Exchange 2016, but not to Exchange 2010.

Where is this limit specified? Can it be changed? We do not know yet. If you do, please let us know.

3.5. LOGbinder troubleshooting tip: Use the Diagnostic Logs

By a wide margin, the support issues we hear about are resolved by revisiting the steps provided in the Troubleshooting section of the LOGbinder application’s Getting Started Guide. Our support desk reports that most customers “self-serve” by checking that section or even the Windows Event Viewer for details, but only after first submitting a trouble ticket. We are happy to have such feedback by the way; it helps us to make sure our installation guides are comprehensive.

But here’s a tip for all the other support issues where such “Tier 1” steps don’t fix the problem: review the LOGbinder diagnostic log file(s). Here’s how to generate this troubleshooting file(s):

1. Choose “File | Options” from LOGbinder control panel.

2. Set “Logging level” to Level 1 and start or restart the service.

3. Waiting for the issue to happen again, find all log files in C:\ProgramData\LOGbinderXX folder (where XX=SP, SQL or EX for the SharePoint, SQL Server or Exchange audit solution). The log files will have a “.log” suffix to the file name. The number of log files in the folder will depend on the LOGbinder application.

Very often the bit of information needed to resolve a problem is contained in the LOGbinder-generated diagnostic log files. Customers often successfully troubleshoot their issues by perusing these files.

If you need our technicians to help you with a particular problem connected to LOGbinder, open a support ticket and attach these level 1 diagnostic files (compressed into a zip file). Doing so will greatly decrease the time it takes for our technicians to help you solve the problem. Many of the initial questions the support desk will have are answered in one or more of these diagnostic log files.

After the problem is resolved, remember to turn off diagnostic logging to conserve disk space and CPU time.

3.6. Dealing with large amount of audit backlog when first starting LOGbinder for Exchange

If you have had auditing enabled on your Exchange server for a while when you install LOGbinder for Exchange (and administrator audit logging is enabled by default), you might have large amount of audit data accumulated, depending on your audit retention period. (SeeAuditLogAgeLimit for mailboxes, and AdminAuditLogAgeLimit for the administrator audit log.)

When starting LOGbinder for Exchange for the first time, LOGbinder will collect and process all audits existing in your Exchange system. If there is a large amount of audit logs, this can take up a considerable time and computational resources on your Exchange server. How can you find out how much audit data you have in your Exchange environment, and what can you do if you do not want to process large amount of backlogs?

Assessing size of audit data

The following Exchange PowerShell command displays the mailboxes with the 20 largest audit data size. It only queries the mailboxes that have auditing enabled.

Get-Mailbox -Filter {AuditEnabled -eq $true} | Get-MailboxFolderStatistics | where {$_.Name -eq "Audits"} | Sort-Object FolderSize -Descending | Select-Object Identity, ItemsInFolder, FolderSize -First 20

The following Exchange PowerShell command displays the size of the administrator audit log.

Get-Mailbox -Arbitration | Get-MailboxFolderStatistics | where {$_.Name -eq "AdminAuditLogs"} | Select-Object Name, ItemsInFolder, FolderSize

If you find that any of the above seems too large (for example, you have hundreds of megabytes of mailbox audit data in some mailboxes), then you might want to consider bypassing those past events, and start the audit log collection with LOGbinder for Exchange from this point forward.

3.7. How to change the LOGbinder service account password

If the password for the LOGbinder service account changes, it also has to be changed on the LOGbinder service.

1. Open Services.msc
2. Find the LOGbinder service and open its properties
3. On the Log On tab, set the new password for the LOGbinder service account

3.8. Tech Tip: How to find the status of Exchange Server 2013 audit log requests

Exchange Server’s audit function is asynchronous. Which makes sense for Exchange but causes security analysts heartburn who have to “wait in faith”. The good news is that you can see the status of those audit requests via a PowerShell cmdlet, but the bad news is that only Exchange 2013 supports it. In Exchange 2013, you can retrieve a list of current audit log searches with the Get-AuditLogSearch cmdlet.

For more tips on application security intelligence, be sure to watch our blog updates at www.logbinder.com/Blog and sign up for the Real Training for Free™ webinars at Ultimate IT Security’s web site.

3.9. Audit log truncation and audit integrity

Occasionally we get feedback from customers that boils down to questions about truncated audit log output. It is important that security analysts and compliance officers understand some basic technology aspects of audit log processing because it helps them to grasp how audit integrity is preserved within the limits of audit log reporting.

Audit truncation: Just the facts

Some event logs from Exchange and SharePoint contain very large chunks of data. Which is fine, except for a simple and incontrovertible fact: there is a limit to the amount of data that can be written to common audit log outputs such as the Windows Event and Security log and Syslog.

• Windows Event and Security log limit events from about 27,000 to 32,000 bytes.
• Some implementations of Syslog limit the size to 65,000 bytes, while other Syslog variants have different limits.

An example of an excessive event in SharePoint would be when someone changes the layout of a list or document library, or adds a rule to sort the list: event 23 will include tons of information about all the schema changes which quickly adds up to tens of thousands of bytes. Another example: Exchange includes a field on some events called “Additional information” that can contain thousands of bytes only marginally-important from a security perspective.

There is no byte limit to file outputs.

What you need to know about audit integrity and LOGbinder’s audit log truncation

LOGbinder puts audit integrity ahead of other considerations in the course of its work. This does not mean that we don’t truncate logs when the required output demands it. For customers whose SIEM requires an output that imposes a limit to the size of recorded event, a decision must be made on how to deliver the event. (It would be unacceptable to just skip it and fail to deliver the audit event.)

In the case of an excessive byte-sized event, LOGbinder makes the decision to truncate what we view to be extraneous: information that can be retrieved via other means (such as the schema change we mentioned earlier) or that is less important to SIEM security analysts than the particulars about the event such as the “who did it, what did they do, and where did it happen”. Those field data elements are never too big.

When we truncate the event, we take extra care to deliver all that is possible. Our very cool technology truncates events only to the size insisted on by the SIEM-specific Syslog implementation for example, starting with the full amount and reducing until it is accepted.

Of course, no such truncation takes place if the LOGbinder output is directed to a plain text file.

It should be stated that, by a wide margin, most use-cases never encounter this issue. Security officers and SysAdmins have good reasons to narrow their monitoring focus to the most relevant audit events. They exclude the noise events which are typically those that would require truncation.

Audit integrity has always been a LOGbinder core value. Our architects and developers have gone to great length to ensure security analysts have what they need from audit logs, both for real-time security event information and forensic investigations– despite hard-coded technological limitations in common event logging formats. The ability to simultaneously direct output to a file that has no byte limitation is an expression of our core value.

LOGbinder for SharePoint even has a feature to configure “lookup levels” to allow organizations to configure their own suitable balance between system performance and the collected audit log detail.

3.10. No "Send-As" audit events in Exchange Server 2013

Some customers have reported “Send-As” events missing from Exchange Server 2013. This issue occurs when the user and the mailbox are located in different Active Directory sites. Microsoft resolved this issue in the Cumulative Update 10 for Exchange 2013. See this KB article for more information about the problem and solution:https://support.microsoft.com/en-us/kb/3074823

3.11. .NET Framework update incompatible with Exchange Server

On 10 February 2016 Microsoft posted a notice to remind customers that Exchange is not compatible with the .NET Framework 4.6.1 that was recommended as an update on 9 Feb 2016. In fact, there are known issues if the new version is installed.

The Exchange Team blog post told Exchange customers to delay upgrading to .NET Framework 4.6.1, and updated their post 12 Feb 2016 to provide the steps to roll back to .NET Framework 4.5.2 if the update took place. You can read the post here:http://blogs.technet.com/b/exchange/archive/2016/02/10/on-net-framework-4-6-1-and-exchange-compatibility.aspx.

LOGbinder is targeted to .NET Framework 3.5 for compatibility reasons. Many customers reported issues when we targeted 4.x.

3.12. Bulletin: Exchange Cumulative Update breaks auditing

Update

This issue is likely not related to cumulative updates, as stated below, but to Exceeding the maximum number of audit log search requests.

---

The issue

In December 2016 Microsoft released the following cumulative updates for Exchange Server:

• Exchange Server 2016 CU4
• Exchange Server 2013 CU15
• Exchange Server 2010 CU16

Early in 2016, our development team discovered that auditing in Exchange 2016 was not functioning properly.  Even without LOGbinder installed, the New-AdminAuditLogSearch and the New-MailboxAuditLogSearch cmdlets were successfully issued but the problem we discovered was that in many Exchange environments, the audit requests were never processed.  The audit request would fill up a queue and then subsequent requests would fail with the error "You have exceeded the maximum number of audit log search requests that your organization can submit. Please try again later."  (See below)

 

It has recently been reported to us by some customers that they are now receiving these same results in Exchange 2013 and Exchange 2010.  It appears that the latest cumulative updates have introduced undocumented changes to auditing that break LOGbinder for Exchange. LOGbinder relies on a functioning Exchange environment to work properly.  Specifically, the new-adminauditlogsearch and new-mailboxauditlogsearch cmdlets must be functioning properly in order for LOGbinder to work.

 We are currently working with one of our contacts at Microsoft to determine if this is a known Exchange issue or if we have discovered another Exchange bug (previously we discovered the 24 hour bug in Exchange).

Our recommendation:

At this time, if you are a current LOGbinder for Exchange customer or a prospective customer, we recommend that you do not update to the latest cumulative updates in the bullet points at the start of this article.  If you do so, you may risk breaking auditing in Exchange which will in turn break LOGbinder for Exchange.

Do you have the issue:

If you are having the symptoms described above or suspect you may have this issue, please follow these steps:

1. Which version of Exchange are you using and which cumulative update do you have installed?
• For Exchange 2010 run this command in Exchange Management Shell: Get-Command ExSetup | ForEach {$_.FileVersionInfo} 
• For Exchange 2013 run this command in Exchange Management Shell: Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
• Now compare your results to this page:  https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx
2. If you are using the latest update and have been issuing audit requests you need to check to see if the audit request queue is full.
• In Exchange Management Shell run:  "new-adminauditlogsearch -startdate "1/25/2017 5:14:45 PM" -EndDate "1/25/2017 5:25:04 PM" -StatusMailRecipients ServiceAccountMailbox@YourDomain.local -name test"
Please note you will have to modify the above command to use a mailbox in your organization. If you are a current LOGbinder for Exchange customer you will probably be using the mailbox related to the service account user you are using in LOGbinder.
• Do you receive an error similar to what is shown in the screenshot above?

If so please contact us and tell us your Exchange version, Cumulative Update version and a screenshot of the error after running the audit request.

3.13. New technical updates posted and available for customers with current maintenance and support contracts - July 2015

Within the last few weeks (July 2015) we posted new versions of our software containing features and improvements to all 3 of our applications. Two major features will bring immediate performance benefits:

1. Split Syslog output if over 100mb. Prior to this update, LOGbinder started a new Syslog output every day (with the file named appropriately), but some organizations’ audit activities would generate more than 1GB of data in a day. This large output file size caused problems. So, we updated all 3 of our applications to create a new file after every 100mb of output and creating a file name suited to this new schema.
2. Streamlined internal audit request and delivery process. To protect the monitored application’s performance and stability, LOGbinder carefully manages the process by which it requests audit log data. Persistent audit log demands can cause harm to the application. We have released an update to all 3 of our products that adds further refinement to the audit request technology by improving the calculated times for audit request and processing. The net effect is reduced resource demand on the monitored application while maintaining delivery speed and audit integrity.

The new updates are available via the website’s download resource page. Customers with current support and maintenance contracts may download and apply these new updates at no additional charge.

4.1. LOGbinder for Exchange Version History

LOGbinder for Exchange 5.0.1 (11/14/2023)

• User interface accessibility improvements

LOGbinder for Exchange 4.1.4 (9/26/2022)

• Add Exchange 2019 actions
• Add MailboxUpdate events (25014-25016)
• Trim long events before writing to event log
• Better error reporting for FIPS related issues
• Change minimum requirement to .NET Framework 4.8

LOGbinder for Exchange 4.0.1 (11/13/2019)

• Redesign mailbox audit actions wizard
• Add MailboxLogin audit action
• Add "Apply Now" button for audit policy wizard
• Speed up outputting to Syslog and Syslog files
• Utilize Get-AuditLogSearch, if available, to avoid too many audit log request
• Better error reporting if New-MailboxAuditLogSearch or New-AdminAuditLogSearch errors
• Delete old transactions based on "Initiated" date, not on "Completed" date
• Add error handling for corrupted settings file
• Retry certain failed actions a few times, in case the problem is temporary
• Many bug fixes and other improvements

LOGbinder for Exchange 3.4.41 (5/2/2019)

• Retry creating/opening Syslog files on error
• Add noise event statistics (number of noise events suppressed)
• Fix noise event filtering for all outputs

LOGbinder for Exchange 3.4.29 (1/1/2019)

• Renewed certificate

LOGbinder for Exchange 3.4.28 (12/9/2018)

• Try to reopen runspace if it is in 'Broken' state
• Delete unused .stg files

LOGbinder for Exchange 3.4.26 (6/3/2018)

• Corrected some CEF problems (escaping '=' signs and a duplicate field in some events)
• Added more error resilience during some Exchange operations

LOGbinder for Exchange 3.4.25 (3/9/2018)

• Handle multiple NICs correctly for Syslog outputs

LOGbinder for Exchange 3.4.23 (12/22/2017)

• Fixed Syslog date to use US format of month names instead of internationalized versions
• Added feature to select inputs by searching for text included in their names
• Added date range to event 551
• Fixed an issue relating inspection
• Fixed a small regression bug
• Increased allowed memory threshold

LOGbinder for Exchange 3.4.22 (9/14/2017)

• Handle error when not being able to find an organizational unit

LOGbinder for Exchange 3.4.21 (8/31/2017)

• Added more error resilience while getting mailboxes in the audit wizard
• Catch and report on certificate errors
• Fixed a date issue due to regional settings
• Increased LOGbinder service startup timeout

LOGbinder for Exchange 3.4 (2/24/2017)

• Added statistics to informational events
  • Information includes processed file names, elapsed time, EPS (events per second)
• Refined service start/stop process
• Improved resilience when there are connection problems while creating a PowerShell session
• Improved resilience when there are connection problems while reading audit data
• Sort input transaction descending for easier navigation to latest entries
• Changed some LOGbinder message terminology
• Added option to specify installation folder other than the default
• Several other updates and improvements

LOGbinder for Exchange 3.3.5 (7/11/2016)

• Fixed version number in all Syslog outputs
• Removed reporting and event nodes from the Control Panel
• Installer grants permission to the ProgramData folder for the service account
• Installer removes previous installations before installing new version
• Improvement in transaction file processing if the LOGbinder service has been stopped for a few days
• Bug fix related to transaction entries in the input properties transactions list
• Bug fix for additional audit requests issued when service is restarted
• Bug fix for disabled "Go" button in Audit Policy Wizard when Groups are selected
• Added additional details to diagnostic event 552
• Added warning message to application log if Exchange fails to deliver audit results

LOGbinder for Exchange 3.1.11 (3/25/2016)

• Bug fix for blank subject emails to the recipient account

LOGbinder for Exchange 3.1.9 (1/16/2016)

• Bug fix for outputting LEEF in UDP

LOGbinder for Exchange 3.0.12 (6/20/2015)

• Due to reports from some LOGbiner for Exchange enterprise customers, changes were made to use .NET 3.5 instead of .NET 4.0

LOGbinder for Exchange 3.0.3 (4/24/2015)

• Mailbox Audit policy
  • Once a day, LOGbinder service will check audit policy on mailboxes that are members of selected groups or organizational units. If policy does not match, LOGbinder will set audit policy, afterward reporting on the results (event 25012)
  • To set mailbox audit policy, click link in Input properties window or Options. Choose which groups, organizational units, then specify the policy.
    • You may select groups, organizational units, or both. Keep in mind it is best to use a fewer number of groups/units, since the greater number of groups/units, the longer it will take LOGbinder to examine them.
    • When pressing Finish, the mailbox audit policy is saved to LOGbinder's settings. Nothing is changed in Exchange until the the LOGbinder service's daily maintenance tasks are done, typically about 1:00 a.m.
• Autofill defaults for Powershell/Exchange URLs
  • When clicking Powershell button, it will create the URL based on current machine. This can be adjusted afterward. (It will also attempt to find the Exchange URL and autofill that.)
  • When clicking the Exchange button, it will look up the Exchange environments available. If more than one, it will present the user with a choice. If only one, it will fill the box.
  • For both, it will prompt before overwriting existing values.
• Recipient for audit emails
  • Since Exchange will send audit logs via email, a mailbox must be used as an intermediate step to processing audit logs. Previously, the address had to be the default administrator mailbox. Now, any email address can be used, provided that it has permissions to receive audit logs, and that the LOGbinder service has access to the mailbox's items.
• Added events 25661-25686, from Exchange service packs
• Adjusted formatting of events
  • For events that list mail items, instead of including redundant XML, extract the subject lines of each item and present as a list
  • This affects events 25001, 25006, 25007, 25010
• For audit log search events, determine if the event was triggered by LOGbinder. If so, treat as noise event. Otherwise, handle as previously with events 25210 and 25190.
• A number of other fixes and improvements

LOGbinder EX 2.5.33 (1/2/2015)

• Fix incorrect tagging of some Syslog outputs

LOGbinder EX 2.5.32 (12/2/2014)

• Fix bug which causes overlapping searches

LOGbinder EX 2.5.28 (10/24/2014)

• Add support for LEEF output

LOGbinder EX 2.5.16

• Fix bug where enabling security log created error when starting service from Control Panel

LOGbinder EX 2.5.15

• Fix retried transactions so mark as completed

LOGbinder EX 2.5.13

• If attached file is not valid XML, will write error message and mark as complete
• Create default transactions when new input is created
• Fix transaction writing so does not write A B C D

LOGbinder EX 2.5.5 (9/2/2014)

• Add to Options the ability to change LOGbinder's output directory
• Purge settings: completed transactions older than a month will be purged to keep the settings file size manageable
• Allow to set "Last Processed" for mailbox and admin events
• Allow to use network location for Syslog output, by changing Alternate Output Directory in Options
• Add Test button to Output properties of Syslog outputs to test connection
• Adjust Output window to indicate that date is part of CEF/Syslog file name
• Make LOGbinder Control Panel / Service start more efficiently
• Rework caching to ensure efficiency
• Do not process event backlog when starting
• Mail message processing: detect known errors contained in messages and mark the transaction 'ERRORED'
• Throttling: allow no more than 7 queries to the Exchange server at any time
• Better handling of "transactions" in settings
• If requests to Exchange take longer than 24 hours, then retry so that it doesn't cause throttling.
• Set polling interval automatically, based on internal intelligence; remove polling interview from Options
• Improved way of handling timezones
• Fix issues with logging, stopping service

LOGbinder EX 2.0.2 (1/18/2014)

• Handle memory error from Security log

LOGbinder EX 2.0.0 (9/2/2013)

• Support Exchange 2013
• Add number of active mailboxes to Options
• Licensing based on number of enabled mailboxes
• Give more meaningful message if bad credentials entered during installation
• Adjust installer so installs for all users properly
• Truncate large events written via Syslog
• Not allow getting license count to slow down opening of Control Panel

LOGbinder EX 1.1.8 (7/25/2013)

• Truncates CEF/Syslog messages being sent via UDP at 65000, because of Syslog limitations

LOGbinder EX 1.1.7 (7/15/2013)

• Caches mailbox count, to improve performance for large installations

LOGbinder EX 1.1.6 (6/21/2013)

• Do not perform audit log search if end date is before start date

LOGbinder EX 1.1.4 (4/15/2013)

• Truncate large events being written to Security log
• Improve error reporting

LOGbinder EX 1.1.1 (2/14/2013)

• New event #550 “LOGbinder process report”
• New event #558 “LOGbinder process warning”
• Fixed several small issues

LOGbinder EX 1.0.4 (10/19/2012)

• First release
• Adjusted for variations in email subject line
• Fixed mailbox event handling

4.2. LOGbinder for Exchange FAQ

Where can I learn more about Exchange Server's Auditing capability?

Why do I need LOGbinder for Exchange - can't Exchange send audit events to the Windows event log itself?

What can I monitor with the Exchange auditing and LOGbinder for Exchange?

Will LOGbinder for Exchange slow down my Exchange Server?

Will enabling the auditing on Exchange slow down my environment?

How secure is LOGbinder for Exchange?

Does LOGbinder for Exchange require much configuration?

How do you monitor LOGbinder for Exchange’s health?

Why doesn’t LOGbinder for Exchange include alerting or long term archival capability?

How does LOGbinder for Exchange integrate with my current log management solution?

Which output formats does LOGbinder for Exchange currently support?

How is LOGbinder for Exchange licensed?

Does LOGbinder for Exchange need to be installed on my Exchange Server?

What user credentials must be assigned to LOGbinder for Exchange? Why?

4.3. End User License Agreement

The Software is provided as is and without any warranty.

DISCLAIMER OF WARRANTIES:

Licensor does not warrant any specific level of system functionality, availability or uptime.

LICENSOR HEREBY DISCLAIMS, AND DOES NOT MAKE, ANY AND ALL EXPRESS, IMPLIED, AND STATUTORY WARRANTIES, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES, DUTIES OR CONDITIONS OF MERCHANTABILITY, OF FITNESS FOR A PARTICULAR PURPOSE, OF ACCURACY OR COMPLETENESS OF RESPONSES, OF RESULTS, OF WORKMANLIKE EFFORT, OF LACK OF VIRUSES, OF LACK OF NEGLIGENCE AND OF NON-INFRINGEMENT. WITH RESPECT TO THE SOFTWARE, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT. On occasion, all software has glitches or unforeseen errors, and consequently, Licensor makes no warranties and disclaims any and all warranties that the Software will function without interruption.

EXCLUSION OF INCIDENTAL, CONSEQUENTIAL AND CERTAIN OTHER DAMAGES:

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, IN NO EVENT SHALL LICENSOR BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS OR CONFIDENTIAL OR OTHER INFORMATION, FOR BUSINESS INTERRUPTION, FOR PERSONAL INJURY, FOR LOSS OF PRIVACY, FOR FAILURE TO MEET ANY DUTY INCLUDING OF GOOD FAITH OR OF REASONABLE CARE, FOR NEGLIGENCE, FOR LOSS OF DATA, AND FOR ANY OTHER PECUNIARY OR OTHER LOSS WHATSOEVER) ARISING OUT OF OR IN ANY WAY RELATED TO THE USE OF OR INABILITY TO USE THE SOFTWARE, THE PROVISION OF OR FAILURE TO PROVIDE SUPPORT SERVICES, OR OTHERWISE UNDER OR IN CONNECTION WITH ANY PROVISION OF THIS EULA, EVEN IN THE EVENT OF THE FAULT, TORT (INCLUDING NEGLIGENCE), STRICT LIABILITY, BREACH OF CONTRACT OR BREACH OF WARRANTY OF LICENSOR, AND EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

LIMITATION OF LIABILITY AND REMEDIES:

NOTWITHSTANDING ANY DAMAGES THAT YOU MIGHT INCUR FOR ANY REASON WHATSOEVER (INCLUDING, WITHOUT LIMITATION, ALL DAMAGES REFERENCED ABOVE AND ALL DIRECT OR GENERAL DAMAGES), THE ENTIRE LIABILITY OF LICENSOR WHETHER UNDER ANY PROVISION OF THIS EULA, OR FROM ANY OTHER SOURCE OF LIABILITY, WHETHER IN CONTRACT OR IN TORT, INCLUDING NEGLIGENCE, AND YOUR EXCLUSIVE REMEDY FOR ALL OF THE FOREGOING (EXCEPT FOR ANY REMEDY OF REPAIR OR REPLACEMENT ELECTED BY LICENSOR WITH RESPECT TO ANY BREACH OF THE LIMITED WARRANTY), SHALL BE LIMITED TO THE AMOUNT ACTUALLY PAID, WITHIN THE ONE (1) CALENDAR YEAR PRECEDING THE TIME YOU MAKE A CLAIM TO LICENSOR OF SUCH DAMAGES, BY YOU TO LICENSOR FOR THE SOFTWARE THAT CAUSED THE DAMAGES OR THAT IS THE SUBJECT MATTER OF OR DIRECTLY RELATED TO THE CAUSE OF ACTION. IN NO EVENT WILL LICENSOR BE LIABLE FOR ANY DAMAGES CAUSED, IN PART OR IN WHOLE, BY YOUR FAILURE TO PERFORM YOUR OBLIGATIONS, OR FOR ANY LOSS OF DATA, PROFITS, SAVINGS, OR ANY OTHER CONSEQUENTIAL OR INCIDENTAL DAMAGES, OR FOR ANY CLAIMS BY YOU BASED UPON A THIRD-PARTY CLAIM.

SOME STATES DO NOT ALLOW THE LIMITATION OR EXCLUSION OF LIABILITY FOR CERTAIN TYPES OF DAMAGES, SO THE ABOVE LIMITATIONS OR EXCLUSIONS MAY OR MAY NOT APPLY TO YOU. THE PROVISIONS IN THIS PARAGRAPH WILL APPLY REGARDLESS OF WHETHER YOU ACCEPT THE SOFTWARE.

YOUR EXCLUSIVE REMEDY:

Licensors sole obligation and entire liability, if any, shall be, at Licensor=s option from time to time exercised subject to applicable law, to repair or replace the Software, so long as you return the original Software. If such a remedy is elected by Licensor, you are responsible for any expenses you may incur (e.g. cost of shipping Software to Licensor). Any replaced parts shall become the property of Licensor. Any replaced Software will be warranted with the same limited warranty set forth above for the longer of the amount of time left in the original warranty period or thirty (30) days. To exercise your remedy, contact Licensor at the address listed below.

CONFIDENTIALITY:

You acknowledge the Software, including its source code and know-how relating to such things, constitute confidential information of Licensor (collectively, “Confidential Information”). You (“Disclosee”) will therefore: (a) will take reasonable steps (including those steps that the Disclosee takes to protect its own information that it regards as confidential) to keep the Confidential Information confidential; and (b) will not disclose or otherwise make available, except as otherwise provided by law, the Confidential Information of the other party to any third party except to such directors, officers, employees and agents of the Disclosee who have a need to have access to the Confidential Information of the other party to perform their obligations to the other party under this EULA. The confidentiality provisions of this paragraph will not apply to Confidential Information that: (a) is in the public domain other than as a consequence of a breach of the obligations contained in this EULA to maintain the confidentiality of such Confidential Information; (b) is established by Disclosee’s documents as being known by the Disclosee prior to its disclosure to the Disclosee hereunder or is independently developed by the Disclosee without breach of the obligations contained in this EULA; or (c) has been received by the Disclosee from a third party who is not subject to obligations similar to the obligations contained in this EULA. In the event that the Disclosee receives notice indicating that it may or will be legally compelled to disclose any of the Confidential Information, it will provide Licensor with prompt notice so that the Licensor may at its sole discretion seek a protective order or other appropriate remedy and/or waive compliance with the provisions of this EULA. In the event that such protective order or other remedy is not obtained for whatever reason, or that such other party waives compliance with the provisions of this EULA, the Disclosee may furnish only that portion of the Confidential Information that he or she is legally required to disclose. The foregoing agreements and covenants set forth in this paragraph will be construed as being an agreement independent of the provisions in this EULA. The existence of any claim or cause of action of either party against the other party, whether predicated on this EULA or otherwise, shall not constitute a defense to the enforcement by such other party of any of the covenants and agreements of this paragraph. Each of the parties acknowledges that its failure to comply with the provisions of this paragraph will cause irreparable harm to the other party which cannot be adequately compensated for in damages, and accordingly acknowledges that the other party will be entitled, in addition to any other remedies available to it, to interlocutory and permanent injunction relief to restrain any anticipated, present or continuing breach of this paragraph.

In the event you breach this EULA, Licensor shall have the right, at its sole option, to terminate this EULA or any portion of this EULA, in addition to any other available remedies.

Upon Termination of this EULA. Upon the termination of this EULA: (a) Your confidentiality obligations, as well as any accrued payment obligations to Licensor, shall survive such termination; (b) your license right to the Software shall immediately cease, and (c) you shall: (i) return to Licensor all copies of and media bearing the Software within 10 business days; (ii) delete and erase any copy of the Software copied onto any computer/server pursuant to this EULA; (iii) erase all backup and archival copies of the Software; and (iv) certify in writing to Licensor within ten (10) business days of the termination of this EULA that all copies of the Software have been returned to Licensor or have been erased. You further authorize Licensor, in the event of termination of this EULA, to remotely and/or electronically disable, delete and/or remove the Software from your computer(s), server(s), and system(s). Termination of this EULA shall not limit either party from pursuing other remedies available to it, including injunctive relief, nor shall such termination relieve you from your obligation to pay fees accrued prior to the termination.

MISCELLANEOUS:

If applicable and unless overridden by a separate agreement, this EULA is incorporated into the agreement you have reached with Licensor for the Software, and in the event of any conflict between the terms of such agreement and this EULA, the terms of this EULA shall prevail and govern.

You acknowledge that the Software is of U.S. origin. You agree to comply with all applicable international and national laws that apply to the Software, including the U.S. Export Administration Regulations, as well as end-user, end-use and destination restrictions issued by the U.S. and other governments.

This EULA is governed by the laws of the State of North Carolina. This EULA may only be modified by a writing signed by both you and Licensor.

Disputes concerning or arising out of this EULA shall be submitted to confidential binding arbitration in Greensboro, North Carolina before the Judicial Arbitration and Mediation Service (“JAMS”) pursuant to the Streamlined JAMS Arbitration Rules and Procedures. Each party hereto submits to the jurisdiction of JAMS at the location so indicated above. Any process served in connection with any proceeding arising out of or relating to this EULA may be served upon the party to be served by registered or certified mail at the address listed above. Any such service will have the same effect as personal service within the states so indicated above. The foregoing shall not preclude any party hereto from seeking enforcement outside the relevant state of the arbitration of any order or judgment rendered by any court upon the JAMS award.

Except as expressly provided in this EULA, no amendment or waiver of this EULA shall be binding unless executed in writing by the Customer and Licensor. No waiver of any provision of this EULA shall constitute a waiver of any other provision nor shall any waiver of any provision of this EULA constitute a continuing waiver unless otherwise expressly provided.

If any provisions of this EULA shall for any reason be held illegal or unenforceable, such provision shall be deemed separable from the remaining provisions of this EULA and shall in no way affect or impair the validity or the enforceability of the remaining provisions of this EULA.

This EULA constitutes the entire agreement between the parties pertaining to the subject matter hereof. There are no warranties, conditions, or representations (including any that may be implied by statute) and there are no agreements in connection with such subject matter except as specifically set forth or referred to in this EULA.

Should you have any questions concerning this EULA, or if you desire to contact Licensor for any reason, please send a written communication to: rsmith@montereytechgroup.com.

4.4. Annual Support and Maintenance Terms and Conditions

4.5. Whitepapers, Webinars and SIEM Integration Resources

Click here for various resources about LOGbinder for Exchange.

4.6. Events Generated

Click here for a list of events generated by LOGbinder for Exchange.