[Check_mk (english)] logwatch - Log Application

Archive checkmk-en
1

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

···

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com www.atlific.com

_________________________________

2

What client version are you using? I’m pretty sure logwatch is broken in the 1.2.8p4 Windows client.

Here is my proof. We have a SQL job that fails intentionally and logs to the Application event log. Using the 1.2.6p16 Windows client, and forwarding the logs to the event console, I set up a rule to match
anything. Here is what I see with 1.2.6p16:

“Jul 19 19:57:27 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (0xFDF3AAEFE027924B99E4489D37E1459B) - Status: Failed - Invoked on: 2016-07-19 19:57:27 - Message: The job failed. The Job was invoked by User
monitor. The last step to run was step 1 (Test Step)."

Next, I upgraded the Windows agent to 1.2.8p4. This was the only change I made. The same event console rule matched and showed me the content as this:

“Jul 19 19:52:50 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (DBS - Priority 1: Test Job) - Status: DBS - Priority 1: Test Job - Invoked on: DBS - Priority 1: Test Job - Message: DBS - Priority 1: Test
Job”

Something is wrong with the way the new agent is parsing the event log. My rule originally matched and alerted on ‘Status: Failed’ which is how I found this problem – that string is not found in what the new
agent returns.

···

From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de]
On Behalf Of Oliver O’Boyle
Sent: Tuesday, July 19, 2016 4:49 PM
To: checkmk-en
Subject: [Check_mk (english)] logwatch - Log Application

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room
for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com
www.atlific.com

_________________________________

The information contained in this e-mail and any attachments is confidential and
intended only for the recipient. If you are not the intended recipient, the
information contained in this message may not be used, copied, or forwarded to
third parties or otherwise distributed for any other purpose. Please notify the
sender if you received this e-mail in error and delete the e-mail and its
attachments promptly. Nothing in this e-mail may be used or deemed to form the
basis of a contractual or any other legally binding obligation unless separately
confirmed in writing by an authorized representative of ARMADA.
3

I too am using 1.2.8p4

···

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:24 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

What client version are you using? I’m pretty sure logwatch is broken in the 1.2.8p4 Windows client.

Here is my proof. We have a SQL job that fails intentionally and logs to the Application event log. Using the 1.2.6p16 Windows client, and forwarding the logs to the event console, I set up a rule to match anything. Here is what I see with 1.2.6p16:

“Jul 19 19:57:27 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (0xFDF3AAEFE027924B99E4489D37E1459B) - Status: Failed - Invoked on: 2016-07-19 19:57:27 - Message: The job failed. The Job was invoked by User monitor. The last step to run was step 1 (Test Step)."

Next, I upgraded the Windows agent to 1.2.8p4. This was the only change I made. The same event console rule matched and showed me the content as this:

“Jul 19 19:52:50 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (DBS - Priority 1: Test Job) - Status: DBS - Priority 1: Test Job - Invoked on: DBS - Priority 1: Test Job - Message: DBS - Priority 1: Test Job”

Something is wrong with the way the new agent is parsing the event log. My rule originally matched and alerted on ‘Status: Failed’ which is how I found this problem – that string is not found in what the new agent returns.

From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de] On Behalf Of Oliver O’Boyle
Sent: Tuesday, July 19, 2016 4:49 PM
To: checkmk-en
Subject: [Check_mk (english)] logwatch - Log Application

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com www.atlific.com

_________________________________



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.

4

Try downgrading just your client to 1.2.6pxx and see if your results change.

···

From: Oliver O’Boyle [mailto:ooboyle@atlific.com]
Sent: Wednesday, July 20, 2016 11:34 AM
To: Tost, Lance; checkmk-en
Subject: RE: logwatch - Log Application

I too am using 1.2.8p4

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:24 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

What client version are you using? I’m pretty sure logwatch is broken in the 1.2.8p4 Windows client.

Here is my proof. We have a SQL job that fails intentionally and logs to the Application event log. Using the 1.2.6p16 Windows client, and forwarding the logs to the event console, I set up a rule to match
anything. Here is what I see with 1.2.6p16:

“Jul 19 19:57:27 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (0xFDF3AAEFE027924B99E4489D37E1459B) - Status: Failed - Invoked on: 2016-07-19 19:57:27 - Message: The job failed. The Job was invoked by User
monitor. The last step to run was step 1 (Test Step)."

Next, I upgraded the Windows agent to 1.2.8p4. This was the only change I made. The same event console rule matched and showed me the content as this:

“Jul 19 19:52:50 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (DBS - Priority 1: Test Job) - Status: DBS - Priority 1: Test Job - Invoked on: DBS - Priority 1: Test Job - Message: DBS - Priority 1: Test
Job”

Something is wrong with the way the new agent is parsing the event log. My rule originally matched and alerted on ‘Status: Failed’ which is how I found this problem – that string is not found in what the new
agent returns.

From:
checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de]
On Behalf Of Oliver O’Boyle
Sent: Tuesday, July 19, 2016 4:49 PM
To: checkmk-en
Subject: [Check_mk (english)] logwatch - Log Application

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room
for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com
www.atlific.com

_________________________________



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.

The information contained in this e-mail and any attachments is confidential and
intended only for the recipient. If you are not the intended recipient, the
information contained in this message may not be used, copied, or forwarded to
third parties or otherwise distributed for any other purpose. Please notify the
sender if you received this e-mail in error and delete the e-mail and its
attachments promptly. Nothing in this e-mail may be used or deemed to form the
basis of a contractual or any other legally binding obligation unless separately
confirmed in writing by an authorized representative of ARMADA.
5

I’ve tried upgrading the agent to 1.2.8p4 to see if that makes any difference. The error is generated every hour so I’ll know soon if that change does anything.

···

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:29 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

Try downgrading just your client to 1.2.6pxx and see if your results change.

From: Oliver O’Boyle [mailto:ooboyle@atlific.com]
Sent: Wednesday, July 20, 2016 11:34 AM
To: Tost, Lance; checkmk-en
Subject: RE: logwatch - Log Application

I too am using 1.2.8p4

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:24 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

What client version are you using? I’m pretty sure logwatch is broken in the 1.2.8p4 Windows client.

Here is my proof. We have a SQL job that fails intentionally and logs to the Application event log. Using the 1.2.6p16 Windows client, and forwarding the logs to the event console, I set up a rule to match anything. Here is what I see with 1.2.6p16:

“Jul 19 19:57:27 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (0xFDF3AAEFE027924B99E4489D37E1459B) - Status: Failed - Invoked on: 2016-07-19 19:57:27 - Message: The job failed. The Job was invoked by User monitor. The last step to run was step 1 (Test Step)."

Next, I upgraded the Windows agent to 1.2.8p4. This was the only change I made. The same event console rule matched and showed me the content as this:

“Jul 19 19:52:50 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (DBS - Priority 1: Test Job) - Status: DBS - Priority 1: Test Job - Invoked on: DBS - Priority 1: Test Job - Message: DBS - Priority 1: Test Job”

Something is wrong with the way the new agent is parsing the event log. My rule originally matched and alerted on ‘Status: Failed’ which is how I found this problem – that string is not found in what the new agent returns.

From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de] On Behalf Of Oliver O’Boyle
Sent: Tuesday, July 19, 2016 4:49 PM
To: checkmk-en
Subject: [Check_mk (english)] logwatch - Log Application

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com www.atlific.com

_________________________________



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.

6

Actually, my mistake. This host’s agent is 1.2.6p5. The cmk server is 1.2.8p4, though.

···

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:29 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

Try downgrading just your client to 1.2.6pxx and see if your results change.

From: Oliver O’Boyle [mailto:ooboyle@atlific.com]
Sent: Wednesday, July 20, 2016 11:34 AM
To: Tost, Lance; checkmk-en
Subject: RE: logwatch - Log Application

I too am using 1.2.8p4

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:24 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

What client version are you using? I’m pretty sure logwatch is broken in the 1.2.8p4 Windows client.

Here is my proof. We have a SQL job that fails intentionally and logs to the Application event log. Using the 1.2.6p16 Windows client, and forwarding the logs to the event console, I set up a rule to match anything. Here is what I see with 1.2.6p16:

“Jul 19 19:57:27 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (0xFDF3AAEFE027924B99E4489D37E1459B) - Status: Failed - Invoked on: 2016-07-19 19:57:27 - Message: The job failed. The Job was invoked by User monitor. The last step to run was step 1 (Test Step)."

Next, I upgraded the Windows agent to 1.2.8p4. This was the only change I made. The same event console rule matched and showed me the content as this:

“Jul 19 19:52:50 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (DBS - Priority 1: Test Job) - Status: DBS - Priority 1: Test Job - Invoked on: DBS - Priority 1: Test Job - Message: DBS - Priority 1: Test Job”

Something is wrong with the way the new agent is parsing the event log. My rule originally matched and alerted on ‘Status: Failed’ which is how I found this problem – that string is not found in what the new agent returns.

From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de] On Behalf Of Oliver O’Boyle
Sent: Tuesday, July 19, 2016 4:49 PM
To: checkmk-en
Subject: [Check_mk (english)] logwatch - Log Application

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com www.atlific.com

_________________________________



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.

7

No change.

···

From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de] On Behalf Of Oliver O’Boyle
Sent: July-20-16 11:36 AM
To: Tost, Lance LTost@armada.net; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: Re: [Check_mk (english)] logwatch - Log Application

I’ve tried upgrading the agent to 1.2.8p4 to see if that makes any difference. The error is generated every hour so I’ll know soon if that change does anything.

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:29 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

Try downgrading just your client to 1.2.6pxx and see if your results change.

From: Oliver O’Boyle [mailto:ooboyle@atlific.com]
Sent: Wednesday, July 20, 2016 11:34 AM
To: Tost, Lance; checkmk-en
Subject: RE: logwatch - Log Application

I too am using 1.2.8p4

From: Tost, Lance [mailto:LTost@armada.net]
Sent: July-20-16 11:24 AM
To: Oliver O’Boyle ooboyle@atlific.com; checkmk-en checkmk-en@lists.mathias-kettner.de
Subject: RE: logwatch - Log Application

What client version are you using? I’m pretty sure logwatch is broken in the 1.2.8p4 Windows client.

Here is my proof. We have a SQL job that fails intentionally and logs to the Application event log. Using the 1.2.6p16 Windows client, and forwarding the logs to the event console, I set up a rule to match anything. Here is what I see with 1.2.6p16:

“Jul 19 19:57:27 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (0xFDF3AAEFE027924B99E4489D37E1459B) - Status: Failed - Invoked on: 2016-07-19 19:57:27 - Message: The job failed. The Job was invoked by User monitor. The last step to run was step 1 (Test Step)."

Next, I upgraded the Windows agent to 1.2.8p4. This was the only change I made. The same event console rule matched and showed me the content as this:

“Jul 19 19:52:50 16384.208 SQLSERVERAGENT SQL Server Scheduled Job ‘DBS - Priority 1: Test Job’ (DBS - Priority 1: Test Job) - Status: DBS - Priority 1: Test Job - Invoked on: DBS - Priority 1: Test Job - Message: DBS - Priority 1: Test Job”

Something is wrong with the way the new agent is parsing the event log. My rule originally matched and alerted on ‘Status: Failed’ which is how I found this problem – that string is not found in what the new agent returns.

From: checkmk-en-bounces@lists.mathias-kettner.de [mailto:checkmk-en-bounces@lists.mathias-kettner.de] On Behalf Of Oliver O’Boyle
Sent: Tuesday, July 19, 2016 4:49 PM
To: checkmk-en
Subject: [Check_mk (english)] logwatch - Log Application

How are these descriptions determined? The following is what I see in cmk:

Jul 19 16:00:04 0.2137 Microsoft-SharePoint_Products-SharePoint_Foundation The Workstation service is in an inconsistent state. Restart the computer before restarting the Workstation service.

But this is what is actually in the Windows log:

The SharePoint Health Analyzer detected an error. Drives are running out of free space.

Available drive space is less than twice the value of physical memory. This is dangerous because it does not provide enough room for a full memory dump with continued operation. It also could cause problems with the Virtual Memory swap file: (VEEAM-SRV - C:).

Examine the failing servers and delete old logs or free space on the drives. For more information about this rule, see “http://go.microsoft.com/fwlink/?LinkID=142688”.

Event ID: 2137

_________________________________

Oliver O’Boyle

Director, IT • Atlific Hotels

250 Saint-Antoine W., Suite 400 Montreal, Quebec H2Y 0A3

T: 514.509.5545 C: 514.608.8533 F: 514.509.5498

ooboyle@atlific.com www.atlific.com

_________________________________



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.



The information contained in this e-mail and any attachments is confidential and

intended only for the recipient. If you are not the intended recipient, the

information contained in this message may not be used, copied, or forwarded to

third parties or otherwise distributed for any other purpose. Please notify the

sender if you received this e-mail in error and delete the e-mail and its

attachments promptly. Nothing in this e-mail may be used or deemed to form the

basis of a contractual or any other legally binding obligation unless separately

confirmed in writing by an authorized representative of ARMADA.